From nobody Thu Nov 1 15:00:08 2018 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E46712958B; Thu, 1 Nov 2018 14:59:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154110959830.29553.6414151772410048476@ietfa.amsl.com> Date: Thu, 01 Nov 2018 14:59:58 -0700 Archived-At: Subject: [babel] Secdir early review of draft-ietf-babel-hmac-00 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 Nov 2018 21:59:59 -0000 Reviewer: Robert Sparks Review result: Has Issues This is an early secdir review of draft-ietf-babel-hmac-00 Summary: There are issues in the draft to address Issues: The pseudo-header is IPv4-centric. The protocol allows for multiple HMAC algorithms, but has no mechanism for signaling which one was used. The MUST NOT at the top of page 8 will need to be adjusted after that's worked out. Discussion of what to do at a verifying peer that doesn't implement a chosen algorithm is also needed. Nits: The claim in 1.1 about not requiring persistent storage is contradicted by the definition of the protocol. At the very least, there is the need to persist the most recent (index,PC) seen. The third bullet at the top of page 4 (among different nodes) has its actors confused. As stated, communication between A and C is irrelevant to the communication between B and C. It would be worth building an example of bootstrapping the protocol between two peers that have no previous knowledge of each other. It's concerning to see a document (even a 00) whose point is to secure a protocol have no discussion at all in the Security Considerations section. It will help refine the document to create and maintain a summary of the important security points in this section going forward. From nobody Thu Nov 1 20:28:09 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FDB129BBF for ; Thu, 1 Nov 2018 20:28:08 -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_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 qnKtZxah9oGv for ; Thu, 1 Nov 2018 20:28:06 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 467B8129AB8 for ; Thu, 1 Nov 2018 20:28:06 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id b5-v6so328317pla.6 for ; Thu, 01 Nov 2018 20:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LdULo6rj3Iu+8WxHEwsp5cDEV1LcyzH/81NLm+K1MIU=; b=h5NxAWfuJODLjhLGp5+Cp0psaS3e4WOAQ88GJauyrw1/9Kug1drNfJVy8XVojTvWX0 ZTxUmVvJg7dtAGvpiXxJinCf/AP9Ynt0mpGNDta29zQho7EYK+3BB1a69mKbRPCdG2rv kuhZNz7Tetvr0l71bw+d7iD3zPy1WGXouGjRb1Yz/Zc18H/ZHW++++5Sv7L5YoOYSPGk +DfRnZeQEZxgHoonOiqETQkgqPyzlm55Q0WP/awefArsfJMMD9gZ5lwYUt05LKqj/M9J yMhuVjOxYvNfNm/T+wApDXk0+Vf0H1msR5/bwyMsMfVnHioDpJU4kaBVuxZs3gZ1rOdB uFxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LdULo6rj3Iu+8WxHEwsp5cDEV1LcyzH/81NLm+K1MIU=; b=eljUuNurFp6iMuwBpxKYbzehgIdMfK7AnD6andfoI5LlABjXEI349EATqtwIkWYLwW wxjVsJ0p1lVxYMFOuWW/S2x6wyepazRSC3FdJ4HmBouwjXMZF14bw+wsv4wV1QI/POVB BVm3Frxp+U15DqyG2gua3FzcxTu+6nDtoAGyUYhUaaqT2lPuUi96oxEaGHPakUi0Cu/b KrbC8IPlZl+qk9I706gTTpHc+L1W8n7tDuN5rXsdonaZ+7CTvNp7WgLmoQj00G6pZ3Ke SjL4S5WRDeENoArAX2sX8MF9+5rugiyq9ixn5DR6C/bnnMBlCdNJ/lj/HQYV4nfbqUdC Uysw== X-Gm-Message-State: AGRZ1gLXjwmmii608+c2nQ16K/CoGfN7HNaObdrfnRfqtIiBvLpU0SVQ dletqkCoNRTlwlJTHXYutcngSs4Wun9WrzhBkCwCAXEX X-Google-Smtp-Source: AJdET5fwmDiBye+QifOgMUoopMdH397iFOIV1+UQ4jC/I5yv3a/u++wM0YxEJgB32/4jM81bYCDV5B6GJArxYUI/QM0= X-Received: by 2002:a17:902:a58c:: with SMTP id az12-v6mr10017203plb.266.1541129285533; Thu, 01 Nov 2018 20:28:05 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Thu, 1 Nov 2018 20:27:54 -0700 Message-ID: To: babel@ietf.org Content-Type: multipart/alternative; boundary="0000000000009e04f50579a61f18" Archived-At: Subject: Re: [babel] Early review on 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: Fri, 02 Nov 2018 03:28:09 -0000 --0000000000009e04f50579a61f18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, Juliusz pointed out that I forgot to mention a change that went into -01: it is now forbidden to send IHU unencrypted. This has the advantage of preventing reverse reachability from being established with an untrusted peer, and makes the security boundary of the protocol much simpler to reason about. One side effect is that the RTT extension now needs to use unicast hellos inside the encryption, which should not be an issue. Please let us know if you have comments on this change. Thanks, David On Oct 08, 2018, at 12:25, David Schinazi wrote: > Thank you for your review, Tony. > The authors have updated the draft to incorporate your comments: > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > A diff between -00 and -01 is available here: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-babel-dtls-01 > (note that the links above may take a few minutes to be functional) > Thanks, > David > On Sep 26, 2018, at 14:37, Antoni Przygienda wrote: >> I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D= review of this >> draft. >> https://datatracker.ietf.org/doc/draft-ietf-babel-dtls >> >> Document: draft-ietf-babel-dtls >> Reviewer: Tony Przygienda >> Intended Status: STD >> Summary: >> Choose from this list... >> I have some minor concerns about this document that I think should be >> resolved before it is submitted to the IESG. Concerns are not defects bu= t >> basically request for some clarification in document and reconsideration= on >> minor issues >> Comments: >> =C2=B7 Draft makes inherent sense, of significance for future wo= rk in >> the routing area IMO for other protocols if the security requirements fo= r >> routing keep on tightening >> =C2=B7 I think that the draft will benefit from an explicit >> justification why I solution based on SHA-1 cannot satisfy the security >> profile desired. Reading the draft I assumed that the main requirement w= as >> confidentiality which was incorrect. Discussions with the authors let to >> quite interesting insights that should be captured in the draft IMO. > > =C2=B7 The section explaining that all the babel frames must be >> unicast with DTLS could benefit from a small rewrite to read easier >> =C2=B7 I recommend the authors to rethink where they want to cha= nge >> base spec babel MTU by a hard offset. Even the DTLS can evolve in a >> Backwards compatible manner changing sizes. From experience with tunnels >> and routing protocols it may be better to just keep the original spec a= nd >> imply than an implementation supporting DTLS has to deal with the accord= ing >> size overhead >> >> thanks >> >> --- tony > > --0000000000009e04f50579a61f18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Juliusz pointed out that I forgot to mention a change that went into -01:= it is now forbidden to send IHU unencrypted. This has the advantage of pre= venting reverse reachability from being established with an untrusted peer,= and makes the security boundary of the protocol much simpler to reason abo= ut. One side effect is that the RTT extension now needs to use unicast hell= os inside the encryption, which should not be an issue.

Please let us know if you have comments on this change.
Thanks,
David


On Oct 08, 2018, at 12:25, Da= vid Schinazi <dschinazi@apple.com= >=C2=A0wrote:
Thank you for your review, Tony.
=C2=A0The authors have updated the draf= t to incorporate your comments:
https://tools.ietf.org/html/draft-ietf-babel-dtls-= 01
= =C2=A0
A diff= between -00 and -01 is available here:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-babel-dtls-01
=C2=A0
(note that the links above may take a few minutes to be fu= nctional)
=C2=A0
Thank= s,
David
<= br>
On Sep 26, 2018, at 14:37, Antoni = Przygienda <prz@juniper.net> w= rote:
I have been selected to do a routing directorate =E2=80=9Cearly=E2= =80=9D review of this draft.=C2=A0
https://datatracker.ietf.org/doc/draft-ietf-b= abel-dtls
=C2=A0
Document: draft-ietf-babel-dtls
Reviewer: Ton= y Przygienda
Intended Status: STD
Summary:
Choose from this list..= .=C2=A0
I have some minor concerns about this document that I think shou= ld be resolved before it is submitted to the IESG. Concerns are not defects= but basically request for some clarification in document and reconsiderati= on on minor issues
Comments:
=C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Draft makes inherent sense, of significance for future work in the routing = area IMO for other protocols if the security requirements for routing keep = on tightening
=C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think that the d= raft will benefit from an explicit justification why I solution based on SH= A-1 cannot satisfy the security profile desired. Reading the draft I assume= d that the main requirement was confidentiality which was incorrect. Discus= sions with the authors let to quite interesting insights that should be cap= tured in the draft IMO.
=C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The section explaining = that all the babel frames must be unicast with DTLS could benefit from a sm= all rewrite to read easier
=C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I rec= ommend the authors to rethink where they want to change base spec babel MTU= by a hard offset. Even the DTLS can evolve in a Backwards compatible manne= r changing sizes. From experience with tunnels and routing protocols it may= be better=C2=A0 to just keep the original spec and imply than an implement= ation supporting DTLS has to deal with the according size overhead
=C2= =A0
thanks
=C2=A0
--- tony

--0000000000009e04f50579a61f18-- From nobody Fri Nov 2 03:11:16 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F2712F1A5; Fri, 2 Nov 2018 03:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcQ11gmQef3G; Fri, 2 Nov 2018 03:11: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 D52631288BD; Fri, 2 Nov 2018 03:11: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 wA2AAx69030400; Fri, 2 Nov 2018 11:10:59 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id ABC5446DB0; Fri, 2 Nov 2018 11:11:05 +0100 (CET) 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 9f89-qBtIOCy; Fri, 2 Nov 2018 11:11:03 +0100 (CET) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6543946DA9; Fri, 2 Nov 2018 11:11:03 +0100 (CET) Date: Fri, 02 Nov 2018 11:11:03 +0100 Message-ID: <87ftwjpz60.wl-jch@irif.fr> From: Juliusz Chroboczek To: Robert Sparks Cc: , draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: <154110959830.29553.6414151772410048476@ietfa.amsl.com> References: <154110959830.29553.6414151772410048476@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 02 Nov 2018 11:11:01 +0100 (CET) X-Miltered: at korolev with ID 5BDC22B3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BDC22B3.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 : 5BDC22B3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Secdir early review of draft-ietf-babel-hmac-00 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 Nov 2018 10:11:15 -0000 Dear Robert, Thank you very much for your review. > Issues: > The pseudo-header is IPv4-centric. The diagram in Section 4.1 shows 16-octet addresses, and so, if anything, it is IPv6-centric. I may be missing something, but I don't see any place where we're assuming IPv4. (The intent, of course, is that the pseudo-header is address-family independent -- the diagram shows 16-octet addresses, but we've been careful to avoid mentioning address families in the body text. If you have any advice about how to improve that, we're listening.) > The protocol allows for multiple HMAC algorithms, but has no mechanism for > signaling which one was used. This is the case, and it is the intent -- checking algorithm availability is done at key provisioning time. > The MUST NOT at the top of page 8 will need to be adjusted after that's > worked out. Discussion of what to do at a verifying peer that doesn't > implement a chosen algorithm is also needed. I don't understand. The first point of Section 4.3 looks clear to me -- a node doesn't compute an HMAC for every HMAC TLV it receives, it computes an HMAC for every key it has been provisioned with. Obviously, it knows the algorithm of every key it has been provisioned with (else it would have failed at configuration time), and hence there is no issue computing all required HMACs. Am I missing something? Do you have any suggestions about how to make that clearer? > Nits: > The claim in 1.1 about not requiring persistent storage is contradicted > by the definition of the protocol. At the very least, there is the need > to persist the most recent (index,PC) seen. A node is allowed to lose its state at any time, at the cost of one RTT worth of lost packets (it will need to issue a new challenge to every peer). In particular, it need not persist its state across reboots. You're right, though, that while this is reasonably clear in the Conceptual Overview section ("Consider a peer A that has no information about a pair B (e.g., because it has recently rebooted)"), we need to put an explicit "MAY discard its state at any time" in the normative part. > The third bullet at the top of page 4 (among different nodes) has its actors > confused. As stated, communication between A and C is irrelevant to the > communication between B and C. I have double-checked, and I believe the property is correct as stated. > It would be worth building an example of bootstrapping the protocol between > two peers that have no previous knowledge of each other. We've tried to do that in Section 2: In this situation, A discards the packet and challenges B to prove that it knows the HMAC key. It sends a "challenge request", a TLV containing a unique nonce, a value that has never been used before and will never be used again. B replies to the challenge request with a "challenge reply", a TLV containing a copy of the nonce chosen by A, in a packet protected by HMAC and containing the new value of B's PC. If you have any advice about how to improve this section, we're listening. > It's concerning to see a document (even a 00) whose point is to secure a > protocol have no discussion at all in the Security Considerations section. While we've done our best to describe the claimed security properties of the protocol in Section 1.2, we still need to write up the Security Considerations section. We'll do that as soon as we can spend some time together with my co-authors. Thanks again for your work, -- Juliusz From nobody Fri Nov 2 08:45:40 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69C8126BED; Fri, 2 Nov 2018 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 c8smLR2ohVud; Fri, 2 Nov 2018 08:45:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 12E83124D68; Fri, 2 Nov 2018 08:45:36 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA2FjY7L037801 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 2 Nov 2018 10:45:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: Juliusz Chroboczek Cc: secdir@ietf.org, draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org References: <154110959830.29553.6414151772410048476@ietfa.amsl.com> <87ftwjpz60.wl-jch@irif.fr> From: Robert Sparks Message-ID: <492b5149-aaed-6287-afd4-5a265dc8caa8@nostrum.com> Date: Fri, 2 Nov 2018 10:45:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87ftwjpz60.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [babel] Secdir early review of draft-ietf-babel-hmac-00 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 Nov 2018 15:45:38 -0000 On 11/2/18 5:11 AM, Juliusz Chroboczek wrote: > Dear Robert, > > Thank you very much for your review. > >> Issues: >> The pseudo-header is IPv4-centric. > The diagram in Section 4.1 shows 16-octet addresses, and so, if anything, > it is IPv6-centric. I may be missing something, but I don't see any place > where we're assuming IPv4. > > (The intent, of course, is that the pseudo-header is address-family > independent -- the diagram shows 16-octet addresses, but we've been > careful to avoid mentioning address families in the body text. If you > have any advice about how to improve that, we're listening.) Ok - skimming to fast and had a divide-by-4 error. Sorry. I still think you'll need to say something about how you're building the pseudo-header for IPv4 vs IPv6. Are you assuming that the header would be a different size for IPv4, or the same size with some zero-packing? > >> The protocol allows for multiple HMAC algorithms, but has no mechanism for >> signaling which one was used. > This is the case, and it is the intent -- checking algorithm availability > is done at key provisioning time. So this is me being new to babel itself - I'll go read the base documents more carefully. > >> The MUST NOT at the top of page 8 will need to be adjusted after that's >> worked out. Discussion of what to do at a verifying peer that doesn't >> implement a chosen algorithm is also needed. > I don't understand. The first point of Section 4.3 looks clear to me -- > a node doesn't compute an HMAC for every HMAC TLV it receives, it computes > an HMAC for every key it has been provisioned with. Obviously, it knows > the algorithm of every key it has been provisioned with (else it would > have failed at configuration time), and hence there is no issue computing > all required HMACs. > > Am I missing something? Do you have any suggestions about how to make > that clearer? No, that's all moot. > >> Nits: >> The claim in 1.1 about not requiring persistent storage is contradicted >> by the definition of the protocol. At the very least, there is the need >> to persist the most recent (index,PC) seen. > A node is allowed to lose its state at any time, at the cost of one RTT > worth of lost packets (it will need to issue a new challenge to every > peer). In particular, it need not persist its state across reboots. > > You're right, though, that while this is reasonably clear in the > Conceptual Overview section ("Consider a peer A that has no information > about a pair B (e.g., because it has recently rebooted)"), we need to put > an explicit "MAY discard its state at any time" in the normative part. > >> The third bullet at the top of page 4 (among different nodes) has its actors >> confused. As stated, communication between A and C is irrelevant to the >> communication between B and C. > I have double-checked, and I believe the property is correct as stated. I disagree. I think the clause you have in the "then" part of that sentence stands alone, and the "if" part has no bearing on it. Please explain further how A having accepted a packet from C has any influence whatsoever on whether B will accept a packet from C? Maybe the clause just needs restructuring to avoid the "if <> then <>" form. Perhaps this construction would work better: A copy of a valid packet originally sent from C to A and then replayed to B will be detected at B as invalid if... > >> It would be worth building an example of bootstrapping the protocol between >> two peers that have no previous knowledge of each other. > We've tried to do that in Section 2: > > In this situation, A discards the packet and challenges B to prove > that it knows the HMAC key. It sends a "challenge request", a TLV > containing a unique nonce, a value that has never been used before > and will never be used again. B replies to the challenge request > with a "challenge reply", a TLV containing a copy of the nonce chosen > by A, in a packet protected by HMAC and containing the new value of > B's PC. > > If you have any advice about how to improve this section, we're listening. Apologies for asking you to explain what's probably a simple and obvious thing, but, assuming at the beginning of that sentence that neither A nor B knows the other node's current (index, PC), then at the end of the paragraph, B _still_ doesn't know A's (index, PC). I'm assuming the challenge A sent to B is not protected by the basic mechanism in this draft, or B would have to discard it and challenge A so it could learn what A's (index, PC) was before it could even read the challenge. Can you walk me through the parts of the what you have written (or what you're implying by reference) that makes that clear? clear. > >> It's concerning to see a document (even a 00) whose point is to secure a >> protocol have no discussion at all in the Security Considerations section. > While we've done our best to describe the claimed security properties of > the protocol in Section 1.2, we still need to write up the Security > Considerations section. We'll do that as soon as we can spend some time > together with my co-authors. > > Thanks again for your work, > > -- Juliusz From nobody Fri Nov 2 11:22:02 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC331276D0; Fri, 2 Nov 2018 11:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMihIIFhHQNz; Fri, 2 Nov 2018 11:21: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 71302124C04; Fri, 2 Nov 2018 11:21: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 wA2ILoVV008561; Fri, 2 Nov 2018 19:21:50 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9780B4BB47; Fri, 2 Nov 2018 19:21:56 +0100 (CET) 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 oLz_D1lh5_0u; Fri, 2 Nov 2018 19:21:54 +0100 (CET) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 084D54BB42; Fri, 2 Nov 2018 19:21:50 +0100 (CET) Date: Fri, 02 Nov 2018 19:21:49 +0100 Message-ID: <87a7mrqr0i.wl-jch@irif.fr> From: Juliusz Chroboczek To: Robert Sparks Cc: secdir@ietf.org, draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: <492b5149-aaed-6287-afd4-5a265dc8caa8@nostrum.com> References: <154110959830.29553.6414151772410048476@ietfa.amsl.com> <87ftwjpz60.wl-jch@irif.fr> <492b5149-aaed-6287-afd4-5a265dc8caa8@nostrum.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 02 Nov 2018 19:21:50 +0100 (CET) X-Miltered: at korolev with ID 5BDC95BE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BDC95BE.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 : 5BDC95BE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Secdir early review of draft-ietf-babel-hmac-00 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 Nov 2018 18:22:01 -0000 > I still think you'll need to say something about how you're building the > pseudo-header for IPv4 vs IPv6. Are you assuming that the header would > be a different size for IPv4, or the same size with some zero-packing? Noted, will do. >>> The protocol allows for multiple HMAC algorithms, but has no mechanism for >>> signaling which one was used. >> This is the case, and it is the intent -- checking algorithm availability >> is done at key provisioning time. > So this is me being new to babel itself - I'll go read the base documents > more carefully. The point here is that the receiver does not need to know the set of HMAC algorithms implemented by the sender: it just computes its own HMAC of the packet, and compares the result (bytewise) with every HMAC TLV included by the sender; if some of the HMAC TLVs use algorithms that are not understood by the receiver, then the comparison fails, and no harm is done. This is, in my understanding, no different from RFC 2328, Appendix D.5.2, paragraph (2) (which is, as far as I know, unchanged by RFC 5709). >>> The third bullet at the top of page 4 (among different nodes) has its >>> actors confused. >> I have double-checked, and I believe the property is correct as stated. > I disagree. I think the clause you have in the "then" part of that > sentence stands alone, and the "if" part has no bearing on it. That's a subtle point, and one that my colleagues and I have spent a significant amount of time thinking about. I'm not happy with the current formulation, but this is the best I can do right now. More below. > A copy of a valid packet originally sent from C to A and then replayed to > B will be detected at B as invalid if... That's too strong. The protocol is designed to protect *multicast* communication, so a packet sent from C to both A and B will be accepted by both A and B. It does not matter if the packet is sent over a link-layer multicast C->A,B, or twice over link-layer unicast C->A,C->B -- in either case, it is accepted by both A and B. The property we have is that if C->A is accepted by A, then C->B is accepted by B only if both of the following are true: - B has previously accepted A's challenge reply; - B hasn't accepted any later packet from A. I agree that this property is confusing, so if you can point us to comparable protocols and the properties that they provably satisfy, then perhaps it could help us find a better formulation of the security properties that we claim. Thanks, -- Juliusz From nobody Tue Nov 6 08:52:20 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EE612F1AC for ; Tue, 6 Nov 2018 08:52:18 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 WInpyIANWWbA for ; Tue, 6 Nov 2018 08:52:15 -0800 (PST) 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 DFF3A130DE7 for ; Tue, 6 Nov 2018 08:52:12 -0800 (PST) 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 wA6Gq4X3012863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Nov 2018 17:52:04 +0100 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 wA6Gq5l6004297; Tue, 6 Nov 2018 17:52:06 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id BA6B367A33; Tue, 6 Nov 2018 17:52:09 +0100 (CET) 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 ZToVNXlRKwx8; Tue, 6 Nov 2018 17:52:07 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 48EA967A2D; Tue, 6 Nov 2018 17:52:07 +0100 (CET) Date: Tue, 06 Nov 2018 17:52:07 +0100 Message-ID: <878t26b13c.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org, babel-users@lists.alioth.debian.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 06 Nov 2018 17:52:05 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 06 Nov 2018 17:52:06 +0100 (CET) X-Miltered: at korolev with ID 5BE1C6B4.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5BE1C6B5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BE1C6B4.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5BE1C6B5.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 : 5BE1C6B4.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5BE1C6B5.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] IETF Babel meeting tomorrow Wednesday 7 November 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 Nov 2018 16:52:19 -0000 Dear all, This is to remind you that the Babel working group will be meeting tomorrow at 15:40 Bangkok (UTC+7) 9:40 Paris (UTC+1) 3:30 New York, NY 0:30 San Luis Obispo, CA Remote participation is free and warmly welcome. Please see https://www.ietf.org/how/meetings/103/remote/ and choose « Boromphimarn 3 ». See you all tomorrow, -- Juliusz From nobody Tue Nov 6 23:47:00 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4819130E30; Tue, 6 Nov 2018 23:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDVN9o-AyKWa; Tue, 6 Nov 2018 23:46:52 -0800 (PST) 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 76A8A130E62; Tue, 6 Nov 2018 23:46:52 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id p83-v6so11224544iod.12; Tue, 06 Nov 2018 23:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=7D6k7V2n+xtoSmSs/RqDb4Kn7/AK9f7kX98utdyqfRc=; b=lGXW8fah2LCPCRHMrgsH6yWCgw2X5veShyUu3lco+KXdaz8/8cf+P6PvM40g54gW3p 1xB8LiXdvwQ+RBJYrjQrz1e4fY80lpZ5RcxoBwA0f2TTezpUbeREd/vydFTuH75Rlyn7 PrZhhSPip+Aa9vOxciS3YHBTQDzrh2rnXCfFDqGaIulaswZRhwR7Or2rTdXznuEaeNkD S164AdXMZOZShj4pnOG6+QEmDHVi63dmwZ67C2jwGC12n9eZgVYtwo5EoR37Oi5zmsu4 oGLu+WEckSOchpxV0Qx12u9VzIfgch1VfUGRHZoR8RLlb/qxrcyRCMGCOmqiuT8yRHGK xRQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=7D6k7V2n+xtoSmSs/RqDb4Kn7/AK9f7kX98utdyqfRc=; b=cas5YnShf3CF8BTZWATBxY4Nkw+pmSrrZ3fm/h8bwfq+nK1UeXSDptVGk1F15fcdU9 KzjELeO1wMEDy3wFzW3vJS65u7z8nFeAZcP8lElXaa9LGhxeI8zKCBvYyf7mPl9gONsU EReX+UkH4vcGKTXZw0TIHQHi1C9s6eLXsHLt7kNIREWzvV/gZN9hUAIbKy0J6fbXxLns FUxcI1reemLo4lonVBw0GgPytBoQbGKRrmZn98IZbRad6v6hmC67E1XSoxT6jWQVMAkq S0uXX9FiMpVmof5glSsB9DtOjf37mfHckQb/P7cxy0kfxOURZgxyE4Z1KTLzTgdenS7G xfVg== X-Gm-Message-State: AGRZ1gKskzakdoe6AnSvADLI7ia51+YaQxxu82IR14Dp8nyuNFLn9f9k SVZiLxAtDLrbEXQ0gf8K2MUr/hDeXmZI2ywN9f7897dXxS0= X-Google-Smtp-Source: AJdET5d9N7wDGdxSPVhsUiAOFlYJoTL7DNXqtIT7I1U8HrH0PXsRTV9xyoiHqPnDMKmtakz+ZRC6fbq7OwZPtZV7IGE= X-Received: by 2002:a6b:acc5:: with SMTP id v188-v6mr669009ioe.66.1541576811382; Tue, 06 Nov 2018 23:46:51 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Wed, 7 Nov 2018 02:46:40 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="0000000000003c9058057a0e522a" Archived-At: Subject: [babel] Shepherd review of draft-ietf-babel-applicability-04 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 Nov 2018 07:46:59 -0000 --0000000000003c9058057a0e522a Content-Type: text/plain; charset="UTF-8" Looks good except that a typo seems to have been introduced in the last update. In particular, in Section 2.2 OLD o strict monotonicity of the metric: for any metric M and link cost C, < C + M; NEW o strict monotonicity of the metric: for any metric M and link cost C, M < C + M; ^^ Although this is a pretty minor change, i think the draft should be fixed before publication is requested. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com --0000000000003c9058057a0e522a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks good except that a typo seems to have been introduce= d in the last update. In particular, in Section 2.2

OLD
=C2=A0 =C2=A0o =C2=A0strict monotonicity of the = metric: for any metric M and link cost
=C2=A0 =C2=A0 =C2=A0 C, < C + = M;
NEW
=C2=A0 =C2=A0o =C2=A0strict monotonicity of the metric: for an= y metric M and link cost
=C2=A0 =C2=A0 =C2=A0 C, M < C + M;
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0^^

Although this is a pretty minor change, i think the draf= t should be fixed before publication is requested.

Thanks,Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-50= 8-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
= =C2=A0d3e3e3@gmail.com
<= /div> --0000000000003c9058057a0e522a-- From nobody Wed Nov 7 03:15:58 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5492A129BBF; Wed, 7 Nov 2018 03:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihZN5ESENzOZ; Wed, 7 Nov 2018 03:15:54 -0800 (PST) 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 3CF0D129619; Wed, 7 Nov 2018 03:15:53 -0800 (PST) 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 wA7BFgkw018415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Nov 2018 12:15:42 +0100 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 wA7BFhDk020527; Wed, 7 Nov 2018 12:15:43 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DAA03598DB; Wed, 7 Nov 2018 12:15:47 +0100 (CET) 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 MaOvG84g6o30; Wed, 7 Nov 2018 12:15:45 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id ACB2A598D9; Wed, 7 Nov 2018 12:15:45 +0100 (CET) Date: Wed, 07 Nov 2018 12:15:45 +0100 Message-ID: <87va59jfz2.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , babel-chairs , David Schinazi In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 07 Nov 2018 12:15:42 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 07 Nov 2018 12:15:43 +0100 (CET) X-Miltered: at korolev with ID 5BE2C95E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5BE2C95F.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BE2C95E.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5BE2C95F.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 : 5BE2C95E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5BE2C95F.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] Shepherd review of draft-ietf-babel-applicability-04 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 Nov 2018 11:15:56 -0000 > OLD > o strict monotonicity of the metric: for any metric M and link cost > C, < C + M; > NEW > o strict monotonicity of the metric: for any metric M and link cost > C, M < C + M; > ^^ > Although this is a pretty minor change, i think the draft should be fixed > before publication is requested. Thanks, fixed in git. I'll wait until tomorrow to see if I get any feedback from the meeting, then submit new revisions of both applicability and 6126bis. As to HMAC, we need to write a Security Considerations section, so it might take a few days (Weronika is busy). -- Juliusz From nobody Wed Nov 7 03:21:14 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285C3129619 for ; Wed, 7 Nov 2018 03:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-youFshVauz for ; Wed, 7 Nov 2018 03:21:12 -0800 (PST) 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 E4474128CF2 for ; Wed, 7 Nov 2018 03:21:11 -0800 (PST) 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 wA7BL4VX021658 for ; Wed, 7 Nov 2018 12:21:04 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 593EB59A4B for ; Wed, 7 Nov 2018 12:21:10 +0100 (CET) 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 GGLM_Jl6W0ny for ; Wed, 7 Nov 2018 12:21:08 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6507B59A48 for ; Wed, 7 Nov 2018 12:21:08 +0100 (CET) Date: Wed, 07 Nov 2018 12:21:08 +0100 Message-ID: <87tvktjfq3.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]); Wed, 07 Nov 2018 12:21:04 +0100 (CET) X-Miltered: at korolev with ID 5BE2CAA0.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BE2CAA0.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 : 5BE2CAA0.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] Information model and YANG: about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 11:21:13 -0000 My comment during the meeting, expanded. HMAC does not carry keys or algorithm identifiers on the wire: algorithm and key are provisioned by means outside of the Babel protocol (currently a configuration file, but we're working on implementing key rotation at runtime), then only the results of the HMAC computation are sent on the wire. Hence, the base protocol does not need a registry of HMAC algorithm identifiers: the only place where HMAC algorithms appear is the config file, and how they are expressed there is purely a local implementation decision. What the information model and YANG do is, among other things, to export the configuration in an interoperable format. Hence, if we need to export the HMAC keys, we'll need a registry of HMAC protocols. If we do, then the initial value should probably be just one entry: HMAC-SHA256. -- Juliusz From nobody Wed Nov 7 03:22:56 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDA3128CF2; Wed, 7 Nov 2018 03:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYkDl-kxrRvZ; Wed, 7 Nov 2018 03:22:54 -0800 (PST) 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 66F45128A5C; Wed, 7 Nov 2018 03:22:54 -0800 (PST) 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 wA7BMkAY022810; Wed, 7 Nov 2018 12:22:46 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 64AC059AB6; Wed, 7 Nov 2018 12:22:52 +0100 (CET) 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 hxzPf6Rmu-3o; Wed, 7 Nov 2018 12:22:50 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 76D7A59AB1; Wed, 7 Nov 2018 12:22:50 +0100 (CET) Date: Wed, 07 Nov 2018 12:22:50 +0100 Message-ID: <87sh0djfn9.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , babel-chairs , dschinazi.ietf@gmail.com In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 07 Nov 2018 12:22:46 +0100 (CET) X-Miltered: at korolev with ID 5BE2CB06.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BE2CB06.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 : 5BE2CB06.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] Shepherd review of draft-ietf-babel-applicability-04 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 Nov 2018 11:22:56 -0000 (Fixed David's mail in CC.) > OLD > o strict monotonicity of the metric: for any metric M and link cost > C, < C + M; > NEW > o strict monotonicity of the metric: for any metric M and link cost > C, M < C + M; > ^^ > Although this is a pretty minor change, i think the draft should be fixed > before publication is requested. Thanks, fixed in git. I'll wait until tomorrow to see if I get any feedback from the meeting, then submit new revisions of both applicability and 6126bis. As to HMAC, we need to write a Security Considerations section, so it might take a few days (Weronika is busy). -- Juliusz From nobody Wed Nov 7 03:25:14 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A725128A5C for ; Wed, 7 Nov 2018 03:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7NddknoBMAu for ; Wed, 7 Nov 2018 03:25:11 -0800 (PST) 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 D0B6A12785F for ; Wed, 7 Nov 2018 03:25:10 -0800 (PST) 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 wA7BP3Wo023952 for ; Wed, 7 Nov 2018 12:25:03 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 441AD59B18 for ; Wed, 7 Nov 2018 12:25:09 +0100 (CET) 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 qIX1S_rRUvHv for ; Wed, 7 Nov 2018 12:25:07 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C0BBC59B12 for ; Wed, 7 Nov 2018 12:25:07 +0100 (CET) Date: Wed, 07 Nov 2018 12:25:07 +0100 Message-ID: <87r2fxjfjg.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]); Wed, 07 Nov 2018 12:25:03 +0100 (CET) X-Miltered: at korolev with ID 5BE2CB8F.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BE2CB8F.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 : 5BE2CB8F.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] Packet trailer 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 Nov 2018 11:25:12 -0000 In RFC6126bis Section 4.2, I say: The packet body and trailer are both sequences of TLVs. The packet body 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. When parsing the trailer, the receiver MUST ignore any TLV unless its definition explicitly states that it is allowed to appear there. Among the TLVs defined in this document, only Pad1 and PadN are allowed in the trailer; since these TLVs are ignored in any case, an implementation MAY silently ignore the packet trailer without even parsing it, unless it implements at least one extension that defines TLVs that are allowed to appear in the trailer. In Appendix C, I say: The packet trailer is intended to carry cryptographic signatures that only cover the packet body; storing the cryptographic signatures in the packet trailer avoids clearing the signature before computing a hash of the packet body, and makes it possible to check a cryptographic signature before running the full, stateful TLV parser. Hence, only TLVs that don't need to be protected by cryptographic security protocols should be allowed to appear in the packet trailer. Any such TLVs should be easy to parse, and in particular should not require stateful parsing. Speak now, or forever hold your peace. -- Juliusz From nobody Wed Nov 7 04:09:55 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7C812D4E9 for ; Wed, 7 Nov 2018 04:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc0UHwZOxGeh for ; Wed, 7 Nov 2018 04:09:50 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BD7129619 for ; Wed, 7 Nov 2018 04:09:50 -0800 (PST) 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=1541592588; bh=5lNQKZYpt1HI0qO6O5oBHykbGoyKzJpdYIIpMy6L3tE=; h=From:To:Subject:In-Reply-To:References:Date:From; b=mp4yb/nLfJlJ6GFqPGNIHsLKlp4Csi9Tr8nnRKKBbVQ637PpX2NLpJZT9H9xOfl2k WA3VEm1CRfK00saRG+EXiLo+g9Ttqq6wNVhoqFOiNDL8u//YSH3c65x6xLlIB4lNBg f9WRcPdtVojbDjjDyTw+FCVY0b6KdZR5cZxdVeQruyubXLIqrSj+XkufZ37m0oFQaW d0EXxrxu/WYBT3prrjSshe4cKKYXomeRI6WxDAs+skCA/ItXasE6Ne7zdeJWZI9GtC jU82ORYtvtU78y2uAwLHaGuhr7T+gMDZF296tVM37pUn813rAUlBfzluCVcpvcocy7 xN9s4DpgBjLZw== To: Juliusz Chroboczek , babel@ietf.org In-Reply-To: <87r2fxjfjg.wl-jch@irif.fr> References: <87r2fxjfjg.wl-jch@irif.fr> Date: Wed, 07 Nov 2018 13:09:47 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877ehpw0l0.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Packet trailer 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 Nov 2018 12:09:53 -0000 Juliusz Chroboczek writes: > In RFC6126bis Section 4.2, I say: > > The packet body and trailer are both sequences of TLVs. The packet > body 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. When parsing the trailer, the > receiver MUST ignore any TLV unless its definition explicitly states > that it is allowed to appear there. Among the TLVs defined in this > document, only Pad1 and PadN are allowed in the trailer; since these > TLVs are ignored in any case, an implementation MAY silently ignore > the packet trailer without even parsing it, unless it implements at > least one extension that defines TLVs that are allowed to appear in > the trailer. > > In Appendix C, I say: > > The packet trailer is intended to carry cryptographic signatures that > only cover the packet body; storing the cryptographic signatures in > the packet trailer avoids clearing the signature before computing a > hash of the packet body, and makes it possible to check a > cryptographic signature before running the full, stateful TLV parser. > Hence, only TLVs that don't need to be protected by cryptographic > security protocols should be allowed to appear in the packet trailer. > Any such TLVs should be easy to parse, and in particular should not > require stateful parsing. > > Speak now, or forever hold your peace. LGTM -Toke From nobody Wed Nov 7 17:16:59 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6499F130DCC; Wed, 7 Nov 2018 17:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBNJksgJ1V1N; Wed, 7 Nov 2018 17:16:56 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 3866E124C04; Wed, 7 Nov 2018 17:16:56 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id n11-v6so13428182iob.6; Wed, 07 Nov 2018 17:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Q9MU7ExEsptfxQsb32J6/u0IU/kdhxNy99SN1id3CmE=; b=mkRBNvDwYFe1J1NFGL9uRbqolUPYLpdrNZmT5gQ5xAgshtU0Lg1HbQO/2yA/ozD4vY WDqz7UAtxTdbRZz8fJsju9tpOZuHjEww/qv0iNzFyAvKTYAYPrqWmyZUwLwj3GCHC3vd ZsNs0oNcoNvzRFF+CLM9Kaq5tFkxq6z8xuyG+/VfVc+ODBdDqPWnLVkzI8ETXRXZkDNZ GtS9Hp12S3NGYorSHMF3ko2uoRj1+lpuNrSWxRRUK/Ynpw2zd2QYBqauJuY0gefirYsD EPfyU4/Kf8k2MQ1CWrSELlGEcbmWXDeCqFT6nb3z15IiI+eXFgOoyJpnOX2IoVY9qa5I nwjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Q9MU7ExEsptfxQsb32J6/u0IU/kdhxNy99SN1id3CmE=; b=NMSHYr8DU49jr84vctoT0HSUW/AAg1cmzcD73VAc87qgq3RV1Edd4PIoQKMiyh1p2+ EgJbljgYPXt3DlLnAjqodMcJQopaKCBTKzlOI/iEV+cCmh3VtIzojoW37YA2NxjUvXDb CUr7Ve2GilvQ/JfF+7wRcqo3Wi585IIvya8HdOi5NE7y3xw6nmJwrCHRtAkJ4ve2QzhB CGXfIQk8ArMNC7T41QYkUgCfEQy/AjNU8yjyYYYRzxm+oyjTcKBtw3+lqlhpKwIW7sbK YGEPdNlKDm2Rjanbg7rz3pJuxN3G1AJbMTo7riY9LcD9XB3JghfbtlvxEJFYlnWX4o2u H1zg== X-Gm-Message-State: AGRZ1gLpe0cs0dPkf8y1Y0bQpRtiH7eV5QUm5OpuxlvEDGkBPRO44YyV JX6DiWkh7wAkJv6qsEldfpEiL8YSjigr2KS/nUmLdVCg X-Google-Smtp-Source: AJdET5doey2Q7/o3NP8mpoNv2eOXzmV5zs0Zd322VaQwlL3Thwu4ArsL4jAOZs1sEm0q5piowyUHx1y7roNQq9aZ1Rg= X-Received: by 2002:a6b:acc5:: with SMTP id v188-v6mr2290531ioe.66.1541639815200; Wed, 07 Nov 2018 17:16:55 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Wed, 7 Nov 2018 20:16:43 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="0000000000008e8ce9057a1cfdb0" Archived-At: Subject: [babel] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 01:16:58 -0000 --0000000000008e8ce9057a1cfdb0 Content-Type: text/plain; charset="UTF-8" This message begins a poll for BABEL WG adoption of draft-mahesh-babel-yang-model-00 running through November 26th. Please indicate whether you think this draft should be adopted as a starting point. Comments on the draft are also welcome. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com --0000000000008e8ce9057a1cfdb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This message begins a poll for BABEL WG a= doption of draft-mahesh-babel-yang-model-00 running through November=C2=A0 = 26th. Please indicate whether you think this draft should be adopted as a s= tarting point. Comments on the draft are also welcome.

Thanks,=
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1= -508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA<= br>=C2=A0d3e3e3@gmail= .com
--0000000000008e8ce9057a1cfdb0-- From nobody Wed Nov 7 17:17:05 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72619130DCC; Wed, 7 Nov 2018 17:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBHTOIrHZZa6; Wed, 7 Nov 2018 17:16:57 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0: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 40621130DC2; Wed, 7 Nov 2018 17:16:57 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id m34-v6so4644617iti.1; Wed, 07 Nov 2018 17:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=P5guVJmAIkO5tZ0kypVWLZXxiLSRTWz0jRYT2V5ACZQ=; b=d8s+G442YprCkiD4s2oVAc9OB1NyPZWVq8Bq+HJtU9AI/FQEmEuZg9JF890Wgp7kxh aC9DxZLC16EB6vJl4Bnq7jlAbabyo6VwvRUAncrLS3rcLPrQgJvhGyKgGSKC23WyoNBg JOu9/lFAPsDhm5kSuDYdBdSJvwdqll11P70Bl933SJCu6vXFsqzCZ2BFir7c7c6exZxd SIsCyENoRTD0e0AFZM9i0kFKGY8eFnfvJ9GFADHxW8e09MPbhMHENOxLPAphzippyz1W IiKSQtoQ2NkbFPVGhGM23TeUfMOfg07d/6KiBD+WYa6h5W1IdJbC5qkOpVK/fEJV3MQn tGSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=P5guVJmAIkO5tZ0kypVWLZXxiLSRTWz0jRYT2V5ACZQ=; b=Ldbzs5ZvJlG2P38TkpZqM8MWFWVatYMjO/JzQ/Thf83twQj8QLkXi7tfwK80BBBjQx 92wrK8oeeLfC5jj4/BWguPMM+9nBYu1/gJC9MNvrkShSyUZRcfi3yb8EXMV7TvvTu+mV ol4AYVftLSUD26nXtexnqwDougFT7lLplsL2f5jCx78grX/u6JSmNMY/nNg2S5jNjcWE a6voUx0FN5WJNrl6VRtp2RLLI4YwpfohjHvel1uUL1IzuzeW4QXQ5qsZeoAIpRm9vNdu wpHvfdgIvoUijuyQUjXlab1gH4/OBh9xwuaomwWJvBoO9DoHK0d7pzQ40TU7fInBcx16 OGkA== X-Gm-Message-State: AGRZ1gJqR6gwZzR39WLEhOlxMSblOa8RRHxesEiPJRlmqZ1IxlBAR2M8 inPbdLK36qs9Pjd1qErtz3ixzEGyxuHGXb0d1WTIqw== X-Google-Smtp-Source: AJdET5d/j6IDXJ11jVpQbZj0lhfwae/8rie1L3TjYdOta0meRcj9S3eYTvOmYhcd0dm1s0FTtVI/kHn96GYZxfq4oWg= X-Received: by 2002:a02:6d5a:: with SMTP id e26-v6mr2451526jaf.39.1541639816230; Wed, 07 Nov 2018 17:16:56 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Wed, 7 Nov 2018 20:16:45 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="0000000000009e44e4057a1cfd10" Archived-At: Subject: [babel] WG Last Call for 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, 08 Nov 2018 01:16:59 -0000 --0000000000009e44e4057a1cfd10 Content-Type: text/plain; charset="UTF-8" This message begins a Working Group Last Call for draft-ietf-babel-dtls-01 running through November 26th. Please indicate whether you think this draft is ready for publication as an RFC. Comments on the draft are also welcome. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com --0000000000009e44e4057a1cfd10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This message begins a Working Group Last Call for draft-ie= tf-babel-dtls-01 running through November 26th. Please indicate whether you= think this draft is ready for publication as an RFC. Comments on the draft= are also welcome.

Thanks,
Donald
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cel= l)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com
--0000000000009e44e4057a1cfd10-- From nobody Wed Nov 7 18:20:53 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F977130E11; Wed, 7 Nov 2018 18:20:49 -0800 (PST) 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_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 9KKTPLhbTR0u; Wed, 7 Nov 2018 18:20:48 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 E3CCF130E07; Wed, 7 Nov 2018 18:20:47 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id w24-v6so8777993plq.3; Wed, 07 Nov 2018 18:20:47 -0800 (PST) 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=Szv4zUcbAtVfCayf48u/qFY0dESinCXoEgBwGITbt0Q=; b=oG5Oh7Niu6HE84zYkc5z4Z+SXap2M4dMPorVTTt6Uc6gLQgAh9wfLMxdl7W1x0nVP/ yRBQSh9yrSvPac7/cBXBKCAWXqYVuvqjVG2rOXL9BK4L0EdDbWInRAeWj+xM+A0szYW2 AuiOkHeMvj+7bqsMZ+0BxWk0cGu3T86EOAHjff0p8UxHAFb5KzC9P1H0gEU/kPawXwq6 YTMh0VyXgpw3bWSPCdJNVc1oSmzCbXqOyPncwt9euhMZ7iIg11UPb2jJX33WZHHgJJwB x+OqdVtoHtJ5QwaOed6EfZMvK1j39OEt3MWoErKvKJjjm1/cdlaQwM+kQAayPMUoVGs9 xHzw== 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=Szv4zUcbAtVfCayf48u/qFY0dESinCXoEgBwGITbt0Q=; b=Idv3yqMA/NVQujCA1V3tC2ioVA8Xm20WbBU/KJE83Jk0z5uGifZMnT0RdEBiz0lCH8 c1G+qUgI6OtLwighz3Vd0qrKU15hMFZazbQAfGmlTByS3N95OtYWpfUmXFblAgvP4qHi u0/dKBqd997r/nAm2HnQ0rnY866l9jYTZHn7NeVAnpQzvt6Au09dQcXpMiVYLqH5peNN K66aeAZsgB3Gc+YzJwby7LV3Qjrwep0Yc3Sl/WS7oKg4eDOGQJTtZae4ha7LaXu1hJUR dlnt3z1kOLLHR2/w84CVVvCnso+jGWOjiAZ3nyqelYu0tZBGGjmSc0yNoV93y4U436DQ mnEQ== X-Gm-Message-State: AGRZ1gKphtvdR/0RDNZD8VLurgxWFlfUv7sNnZRI7RBJWW3fvNPMtAtD yBMf+LpcUi6DekMQuf2C+aDhcYuoLXB0LSJe4BC22w== X-Google-Smtp-Source: AJdET5cgB7LQg4Hwy+t77Zex1nTbPLhVMiYKfeesfWX4VT3dtEVbf1WEal1Lc6kG9+zpoMwuWnRH06WOdVK6bYS8Mmo= X-Received: by 2002:a17:902:a58c:: with SMTP id az12-v6mr2699906plb.266.1541643647498; Wed, 07 Nov 2018 18:20:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Thu, 8 Nov 2018 09:20:36 +0700 Message-ID: To: Donald Eastlake Cc: babel@ietf.org, babel-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000fac173057a1de1ad" Archived-At: Subject: Re: [babel] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 02:20:50 -0000 --000000000000fac173057a1de1ad Content-Type: text/plain; charset="UTF-8" As stated in person yesterday, I support WG adoption of this document. David On Thu, Nov 8, 2018 at 8:17 AM Donald Eastlake wrote: > This message begins a poll for BABEL WG adoption of > draft-mahesh-babel-yang-model-00 running through November 26th. Please > indicate whether you think this draft should be adopted as a starting > point. Comments on the draft are also welcome. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail..com > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000fac173057a1de1ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As stated in person yesterday, I support WG adoption of th= is document.

David

On Thu, Nov 8, 2018 at 8:17 AM Donald Eastlake <d3e3e3@gmail.com> wrote:
=
This messa= ge begins a poll for BABEL WG adoption of draft-mahesh-babel-yang-model-00 = running through November=C2=A0 26th. Please indicate whether you think this= draft should be adopted as a starting point. Comments on the draft are als= o welcome.

Thanks,
Donald
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)<= br>=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail..com
=
_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000fac173057a1de1ad-- From nobody Wed Nov 7 21:16:17 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20197130DCF; Wed, 7 Nov 2018 21:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 q6NK9X0l0Qpc; Wed, 7 Nov 2018 21:16:14 -0800 (PST) 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 9ED2F126CB6; Wed, 7 Nov 2018 21:16:13 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wA82FcnT002879; Wed, 7 Nov 2018 21:18:10 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2nma563fae-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Nov 2018 21:18:09 -0500 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 wA82I8wW014086; Wed, 7 Nov 2018 21:18:08 -0500 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 wA82I4Zi014019; Wed, 7 Nov 2018 21:18:04 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id B209B4014052; Thu, 8 Nov 2018 02:18:04 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30487.vci.att.com (Service) with ESMTPS id A035B401404F; Thu, 8 Nov 2018 02:18:04 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.253]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 21:18:04 -0500 From: "STARK, BARBARA H" To: "'Donald Eastlake'" , Babel at IETF CC: babel-chairs Thread-Topic: [babel] Poll for WG adoption of draft-mahesh-babel-yang-model Thread-Index: AQHUdwDFDnNgk97QPUSoccOccvHdd6VFI0Ww Date: Thu, 8 Nov 2018 02:18:03 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF21734@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.237.99] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DF21734GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-08_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=987 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811080015 Archived-At: Subject: Re: [babel] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 05:16:16 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DF21734GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBmdWxseSBzdXBwb3J0IGFkb3B0aW9uLiBUaGVuIGFnYWluLCBJ4oCZbSBiaWFzZWQuDQpXZSB3 aWxsIGJlIGRvaW5nIHVwZGF0ZXMgdG8gYWxpZ24gd2l0aCB1cGRhdGVzIGRvbmUgdG8gdGhlIGlu Zm8gbW9kZWwuIEFuZCBJ4oCZbSB0YXNrZWQgd2l0aCBwcm92aWRpbmcgdGV4dCBmb3Igc2VjdGlv biAyLjEgSW5mb3JtYXRpb24gTW9kZWwgKHdoaWNoIGlzIGN1cnJlbnRseSBhIGxpdHRsZSBzcGFy c2Ugb24gdmVyYmlhZ2UpLg0KQmFyYmFyYQ0KDQpGcm9tOiBiYWJlbCA8YmFiZWwtYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIERvbmFsZCBFYXN0bGFrZQ0KU2VudDogV2VkbmVzZGF5LCBO b3ZlbWJlciAwNywgMjAxOCA4OjE3IFBNDQpUbzogQmFiZWwgYXQgSUVURiA8YmFiZWxAaWV0Zi5v cmc+DQpDYzogYmFiZWwtY2hhaXJzIDxiYWJlbC1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb YmFiZWxdIFBvbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LW1haGVzaC1iYWJlbC15YW5nLW1v ZGVsDQoNClRoaXMgbWVzc2FnZSBiZWdpbnMgYSBwb2xsIGZvciBCQUJFTCBXRyBhZG9wdGlvbiBv ZiBkcmFmdC1tYWhlc2gtYmFiZWwteWFuZy1tb2RlbC0wMCBydW5uaW5nIHRocm91Z2ggTm92ZW1i ZXIgIDI2dGguIFBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSB0aGluayB0aGlzIGRyYWZ0IHNo b3VsZCBiZSBhZG9wdGVkIGFzIGEgc3RhcnRpbmcgcG9pbnQuIENvbW1lbnRzIG9uIHRoZSBkcmFm dCBhcmUgYWxzbyB3ZWxjb21lLg0KDQpUaGFua3MsDQpEb25hbGQNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCiBEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMzMy0yMjcw IChjZWxsKQ0KIDE0MjQgUHJvIFNob3AgQ291cnQsIERhdmVucG9ydCwgRkwgMzM4OTYgVVNBDQog ZDNlM2UzQGdtYWlsLi5jb208bWFpbHRvOmQzZTNlM0BnbWFpbC5jb20+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114DF21734GAALPA1MSGUSRBF_ 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 IGZ1bGx5IHN1cHBvcnQgYWRvcHRpb24uIFRoZW4gYWdhaW4sIEnigJltIGJpYXNlZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdpbGwgYmUgZG9pbmcgdXBkYXRlcyB0 byBhbGlnbiB3aXRoIHVwZGF0ZXMgZG9uZSB0byB0aGUgaW5mbyBtb2RlbC4gQW5kIEnigJltIHRh c2tlZCB3aXRoIHByb3ZpZGluZyB0ZXh0IGZvciBzZWN0aW9uIDIuMSBJbmZvcm1hdGlvbiBNb2Rl bCAod2hpY2ggaXMgY3VycmVudGx5IGEgbGl0dGxlIHNwYXJzZSBvbiB2ZXJiaWFnZSkuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYXJiYXJhPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IGJhYmVsICZsdDtiYWJlbC1ib3VuY2VzQGlldGYub3JnJmd0 OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KRG9uYWxkIEVhc3RsYWtlPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgTm92ZW1iZXIgMDcsIDIwMTggODoxNyBQTTxicj4NCjxiPlRvOjwvYj4gQmFi ZWwgYXQgSUVURiAmbHQ7YmFiZWxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBiYWJlbC1j aGFpcnMgJmx0O2JhYmVsLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W2JhYmVsXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1tYWhlc2gtYmFiZWwteWFuZy1t b2RlbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIG1lc3NhZ2UgYmVnaW5zIGEgcG9sbCBmb3IgQkFCRUwgV0cgYWRvcHRpb24gb2YgZHJh ZnQtbWFoZXNoLWJhYmVsLXlhbmctbW9kZWwtMDAgcnVubmluZyB0aHJvdWdoIE5vdmVtYmVyJm5i c3A7IDI2dGguIFBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSB0aGluayB0aGlzIGRyYWZ0IHNo b3VsZCBiZSBhZG9wdGVkIGFzIGEgc3RhcnRpbmcgcG9pbnQuIENvbW1lbnRzIG9uIHRoZSBkcmFm dCBhcmUgYWxzbyB3ZWxjb21lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8YnI+DQpEb25hbGQ8YnI+DQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJm5ic3A7RG9uYWxkIEUuIEVhc3RsYWtl IDNyZCAmbmJzcDsgJiM0MzsxLTUwOC0zMzMtMjI3MCAoY2VsbCk8YnI+DQombmJzcDsxNDI0IFBy byBTaG9wIENvdXJ0LCBEYXZlbnBvcnQsIEZMIDMzODk2IFVTQTxicj4NCiZuYnNwOzxhIGhyZWY9 Im1haWx0bzpkM2UzZTNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZDNlM2UzQGdtYWlsLi5j b208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114DF21734GAALPA1MSGUSRBF_-- From nobody Thu Nov 8 00:38:04 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B14113107B for ; Thu, 8 Nov 2018 00:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rGOIBqHdtk8 for ; Thu, 8 Nov 2018 00:37:54 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 A1FCC131021 for ; Thu, 8 Nov 2018 00:37:45 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id p83-v6so14005435iod.12 for ; Thu, 08 Nov 2018 00:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7TweYgfIv0n8ULyA9iK2GTtBRCNdOApKxqPq1JcDekE=; b=RtqTefDrYb9swaXwoBOJaWg5gHTrvQ2Tvct1orYByTzGV4r15GPqXmMKKxkqEqbTgN 5Xud7yQ5vrbgq86mzLBkof6zbzVADYy4KpfsstdQEZBrz85LSa98fNdB10M7M2aL7Cid 1v7FZrUENQl5UWriBrtOQPXOYeYkDNZTxSzjD9SBN2NvytKmq83f1DwdNO9wRz6DK2/N TLd3p6Cqj8PUqNpZNaBRNCafuyIV/cCv4kzdP8ZxF5BxO37DPe5bGgqLgP5GQD0sLXs8 7O7Vtx1VSW41/8zoViFKzmgZ5uiEWweHD8UtJegGAvaM1YxecB40fU0tLoN0lQZEUQeT BI4Q== 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=7TweYgfIv0n8ULyA9iK2GTtBRCNdOApKxqPq1JcDekE=; b=f0rqRqaT/xegxEjg7LeyYvWr/VBDIcZnwhUpASs+qQ9UivlpbEB06G3xt2PfjO+cjU c2wH9A0k0YnXq1HBRyMI8iz7HA55twLa3DPH4OoqaJK2rzJBcVt4eVuazfIxfbfxJAFm LeBKoshNBBxmFblgl3fcJJwiPo8RAXeOtW8ddHPoiU+n0hoJehaAMdGR9ybKOkbRGTgx zcxezrvG7E4heivMGiEBgr8nZoF7F3O6E5iiJGJswgm0GI8IAJ5uhO2Zqqd0ddtBpfS1 HMOne1UNjzLL2HKXAJIL+GnnS0OC/ApLvQDDQV2uPimTi28McmY0LFPNluWq20IR6Ug4 Uk1Q== X-Gm-Message-State: AGRZ1gL98J4bC3eb2CVN0vXKsnjaDzcbuqe5Ds8VoYTcbxHEA53Kz2hB EVP7a1kmhR8tHhxThLrfle5GYiAtsBHM5P0ntoXecA== X-Google-Smtp-Source: AJdET5fh43DkBMuKpzX7AFcEO508VCQQHtP9r0G6FQAp5gicEqhG6pIKZz3BJCv81fpLQaxN2x9kafVS6QK1WC3ECHc= X-Received: by 2002:a6b:c502:: with SMTP id v2-v6mr2857228iof.297.1541666264658; Thu, 08 Nov 2018 00:37:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gabriel Kerneis Date: Thu, 8 Nov 2018 09:37:07 +0100 Message-ID: To: Donald Eastlake Cc: Babel at IETF , babel-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000011d5f6057a23261f" Archived-At: Subject: Re: [babel] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 08:38:01 -0000 --00000000000011d5f6057a23261f Content-Type: text/plain; charset="UTF-8" I support adoption. Gabriel On Thu, Nov 8, 2018 at 2:17 AM Donald Eastlake wrote: > This message begins a poll for BABEL WG adoption of > draft-mahesh-babel-yang-model-00 running through November 26th. Please > indicate whether you think this draft should be adopted as a starting > point. Comments on the draft are also welcome. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail..com > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --00000000000011d5f6057a23261f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption.

Gabriel


On Thu, Nov 8, 2018 at 2:17 AM Donald Eastlake <<= a href=3D"mailto:d3e3e3@gmail.com">d3e3e3@gmail.com> wrote:
This mess= age begins a poll for BABEL WG adoption of draft-mahesh-babel-yang-model-00= running through November=C2=A0 26th. Please indicate whether you think thi= s draft should be adopted as a starting point. Comments on the draft are al= so welcome.

Thanks,
Donald
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)<= br>=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail..com
=
_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--00000000000011d5f6057a23261f-- From nobody Thu Nov 8 03:15:37 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687CE130DE1; Thu, 8 Nov 2018 03:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_Dd-TtOO2yZ; Thu, 8 Nov 2018 03:15:33 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C104130EFE; Thu, 8 Nov 2018 03:15:24 -0800 (PST) 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=1541675719; bh=GoyTxqfSwvxicKbckNIbopUp8+zDDqRBRIIt7E4iQmY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nitdKbzjAmlbz2CmqpyJE4FNsQJhxjyHJCcAAVKh8QHg4Q6Bma7Ldoufo/jkcetUZ LYfqGviha2fPIam82ut4PVYCGNnq0acSL3f9Z1m2uV5HYbWBxWRwjLuf8rAyk2h1yh JGondKEEHJlTKhnCgr51W2YBJIldLVYxga8LO17txIBwyllI0Hu1qCG4lNj797R4hm /oz6npsBNq0/EkCAhmR2OlzLdDubfZtB7xZIKaNQg8kOTvduSUPVQRdA/sfSgC7sbi AEC1mA9USDirxFm7f3ABmdyBL9nO69+D6+hsi1eVPZFx1EQFDr/ONiKBR1C8Eu3Ob/ ksUW6N+Uzqt7g== To: Donald Eastlake , Babel at IETF Cc: babel-chairs In-Reply-To: References: Date: Thu, 08 Nov 2018 12:15:18 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d0rfvn09.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 11:15:37 -0000 Donald Eastlake writes: > This message begins a poll for BABEL WG adoption of > draft-mahesh-babel-yang-model-00 running through November 26th. Please > indicate whether you think this draft should be adopted as a starting > point. Comments on the draft are also welcome. I support adoption. -Toke From nobody Thu Nov 8 03:32:09 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5524126BED; Thu, 8 Nov 2018 03:32:07 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 CR-_bs_uaUEd; Thu, 8 Nov 2018 03:32:06 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83626123FFD; Thu, 8 Nov 2018 03:32:06 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8FC2421B90; Thu, 8 Nov 2018 06:32:05 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 08 Nov 2018 06:32:05 -0500 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=fm1; bh=9LMwNMUUcnnFOZH1XkvzceeLRzK8EbWp/vtQFRrc5 xE=; b=MiS9eE/zNvR98ib1wkqTMeavm5c52szv4ziG7m53VpGYoIWIr8/hvT3qd yA/63LB3oKcLs6Q+777w6kU1aHGWXkD5Zh7Kyc47U1OEEUy4apQUSa0mUqNte45/ zEo4euQ4brW7tIDXDcjyRpDsh4L1CnOPNcWTy46z4jHtNJz3tW6QLEIpS5h54FnN u4ZriZ+6eMT/Zp5xUkNS+o04eszsfcsYLTXPm17KRW7bopA+6jYUgByY3fDCQIen GPIKAUgnwA/xZSvELUz+HaDv3qMVPxbzUrlhcM3rPaAF1PJvUpXVwSyIHNxhmWRO pQ9YG1b43Rl0fEeI/NTQKeB6X5hQA== X-ME-Sender: X-ME-Proxy: Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net [162.229.180.77]) by mail.messagingengine.com (Postfix) with ESMTPA id 1D7C4E4687; Thu, 8 Nov 2018 06:32:05 -0500 (EST) From: "Russ White" To: "'Donald Eastlake'" , "'Babel at IETF'" Cc: "'babel-chairs'" References: In-Reply-To: Date: Thu, 8 Nov 2018 06:32:06 -0500 Message-ID: <02ab01d47756$ae1c9ab0$0a55d010$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF96OPibN+qw7q7RXkYhvx7TPiST6Xy24Ig Content-Language: en-us Archived-At: Subject: Re: [babel] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 11:32:08 -0000 > This message begins a poll for BABEL WG adoption of > draft-mahesh-babel-yang-model-00 running through November 26th. = Please > indicate whether you think this draft should be adopted as a starting = point. > Comments on the draft are also welcome. Support. =F0=9F=98=8A /r From nobody Thu Nov 8 08:41:55 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A1812D4EE; Thu, 8 Nov 2018 08:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVq-uoIC8vGG; Thu, 8 Nov 2018 08:41:50 -0800 (PST) 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 28171128BCC; Thu, 8 Nov 2018 08:41:49 -0800 (PST) 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 wA8GffSR026472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Nov 2018 17:41:41 +0100 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 wA8Gfh06000832; Thu, 8 Nov 2018 17:41:43 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6E25D57A24; Thu, 8 Nov 2018 17:41:47 +0100 (CET) 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 ilg3Ds32A4TJ; Thu, 8 Nov 2018 17:41:45 +0100 (CET) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id F08BC57A1D; Thu, 8 Nov 2018 17:41:44 +0100 (CET) Date: Thu, 08 Nov 2018 17:41:44 +0100 Message-ID: <87efbviks7.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , babel-chairs In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 08 Nov 2018 17:41:41 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 08 Nov 2018 17:41:43 +0100 (CET) X-Miltered: at korolev with ID 5BE46745.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5BE46747.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BE46745.003 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5BE46747.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 : 5BE46745.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5BE46747.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] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 16:41:53 -0000 > This message begins a poll for BABEL WG adoption of > draft-mahesh-babel-yang-model-00 running through November 26th. Support. From nobody Thu Nov 8 16:04:18 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2007A13104D; Thu, 8 Nov 2018 16:04:11 -0800 (PST) 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_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 LeBmTIxntyM9; Thu, 8 Nov 2018 16:04:09 -0800 (PST) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3748130DF1; Thu, 8 Nov 2018 16:04:08 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 8817121471; Fri, 9 Nov 2018 00:04:05 +0000 (UTC) From: Dave Taht To: Juliusz Chroboczek Cc: Donald Eastlake , babel-chairs , Babel at IETF References: <87efbviks7.wl-jch@irif.fr> Date: Thu, 08 Nov 2018 16:03:53 -0800 In-Reply-To: <87efbviks7.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Thu, 08 Nov 2018 17:41:44 +0100") Message-ID: <87bm6zruae.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 00:04:15 -0000 Juliusz Chroboczek writes: >> This message begins a poll for BABEL WG adoption of >> draft-mahesh-babel-yang-model-00 running through November 26th. > > Support. Support. > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Thu Nov 8 16:05:12 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506D6130DDE; Thu, 8 Nov 2018 16:05:10 -0800 (PST) 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_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 qMxM9aAYAaOa; Thu, 8 Nov 2018 16:05:08 -0800 (PST) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6778F130DD5; Thu, 8 Nov 2018 16:05:08 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 115C921471; Fri, 9 Nov 2018 00:05:05 +0000 (UTC) From: Dave Taht To: Donald Eastlake Cc: Babel at IETF , babel-chairs References: Date: Thu, 08 Nov 2018 16:04:54 -0800 In-Reply-To: (Donald Eastlake's message of "Wed, 7 Nov 2018 20:16:45 -0500") Message-ID: <877ehnru8p.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] WG Last Call for 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: Fri, 09 Nov 2018 00:05:10 -0000 Donald Eastlake writes: > This message begins a Working Group Last Call for > draft-ietf-babel-dtls-01 running through November 26th. Please > indicate whether you think this draft is ready for publication as an > RFC. Comments on the draft are also welcome. Is there more than one public implementation at this point? > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Thu Nov 8 23:25:26 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3843A124D68; Thu, 8 Nov 2018 23:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gBzmm7oannz; Thu, 8 Nov 2018 23:25:23 -0800 (PST) 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 C5115130E01; Thu, 8 Nov 2018 23:25:21 -0800 (PST) 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 wA97PDdQ014899; Fri, 9 Nov 2018 08:25:13 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id AE91F5E5F9; Fri, 9 Nov 2018 08:25:19 +0100 (CET) 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 SAlnCd7jf_vN; Fri, 9 Nov 2018 08:25:17 +0100 (CET) Received: from [192.168.0.167] (aaubervilliers-652-1-72-29.w90-61.abo.wanadoo.fr [90.61.95.29]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5E1445E5F7; Fri, 9 Nov 2018 08:25:17 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Matthieu Boutier In-Reply-To: <87bm6zruae.fsf@taht.net> Date: Fri, 9 Nov 2018 08:25:16 +0100 Cc: Juliusz Chroboczek , Donald Eastlake , babel-chairs , Babel at IETF Content-Transfer-Encoding: 7bit Message-Id: <9286092B-CACB-49C3-8646-C03C05E4E5ED@irif.fr> References: <87efbviks7.wl-jch@irif.fr> <87bm6zruae.fsf@taht.net> To: Dave Taht X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 09 Nov 2018 08:25:13 +0100 (CET) X-Miltered: at korolev with ID 5BE53659.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BE53659.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 : 5BE53659.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] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 07:25:25 -0000 I support adoption. Matthieu From nobody Thu Nov 8 23:58:10 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE775130EB7; Thu, 8 Nov 2018 23:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LZcEuY6bFQE; Thu, 8 Nov 2018 23:58:05 -0800 (PST) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4174F130EDF; Thu, 8 Nov 2018 23:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=L61wt/3n2+VpFl2XOZ0sVWp2yXHmGHPgbj7ACP5oFLI=; b=zD6RDkhZCRoGQI6C0tE+0zjK6H 2G0lU4WOiL7Cnh0XbSmi12j2P+Qc2Cr0RMi7vfh2AsM8uV6P8IMsasIgKdJuLpFBxPMsibCUfrSas sdBgvmTBuaHFY0SzqXD+yADo7Hf1vf4dgfhReCiHEs9iENjKtVFC5OOOKSwm7bqMrFaqgptfMMbiH 5MX4Kb8rAC63mctJZE61sZNRXC93+gmEwVIKSPxEYm4RGJIwnpUzekgGiYom3ufkeGcipbv+tyOxi h8i9NaTuF4l+gNSaL1IqePSha8EYwzJcusEQSOPZxmrxJkx9dKt+U0dgbqmlTrKOCRDr30Sr52szG FkKOugcg==; Received: from 91-155-69-202.elisa-laajakaista.fi ([91.155.69.202] helo=[192.168.42.207]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gL1g2-0005HB-9d; Fri, 09 Nov 2018 09:58:02 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Markus Stenberg In-Reply-To: Date: Fri, 9 Nov 2018 09:58:01 +0200 Cc: Babel at IETF , babel-chairs Content-Transfer-Encoding: 7bit Message-Id: <115141A1-8D26-42A6-8AF1-486E4FD286F5@iki.fi> References: To: Donald Eastlake X-Mailer: Apple Mail (2.3445.100.39) X-SA-Exim-Connect-IP: 91.155.69.202 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Poll for WG adoption of draft-mahesh-babel-yang-model 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 Nov 2018 07:58:09 -0000 +1. I think it is a good start. -Markus From nobody Fri Nov 9 00:29:28 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35703127332 for ; Fri, 9 Nov 2018 00:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, RCVD_IN_SORBS_WEB=1.5, 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 gca6-6tru80E for ; Fri, 9 Nov 2018 00:29:25 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0: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 C9CAF124D68 for ; Fri, 9 Nov 2018 00:29:25 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id y4so544491pgc.12 for ; Fri, 09 Nov 2018 00:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=19JQ3NuxB7l2XXQtPth9CjTocGqqZjNVrnXWwNCU+vM=; b=PTKhFwa6fHHaJY5tdL4KoSeF2hdBCNXcFCkbX5UukJDCWgi8BK9klcNls1xC4f6aD8 SJ4OkiYyzDa2vtUXMVKg1tfajy6/2ud63o+xhP5yCmf6jJxhZL3C30hlIJRLIB0e7yaL u6Mev/8H3uBW85bpb3BSJU4F3er0nlidA+/NKa8b1YVqDL/84Cd55Uvu77hEjjA6djkw Hduv5ckPPsCQEKBZSYIX8dWXV8jvGpy1kaOlHOgG4aeOMQjAKYA1ARtjdwP0IUoXBU64 GtsHXixgK4jVPQAo9+20LWejdhDREQdSW38t0pVqnHlpJYTLpLLo5zZ4OL1n0Us6lq55 qDKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=19JQ3NuxB7l2XXQtPth9CjTocGqqZjNVrnXWwNCU+vM=; b=YvYB0zmScBHlo6F+w3/ur+sHnbJ7ACJhdeVolbKMG2ukWmhimhhvzk5Jbefw5M7X7d dLQnmABJLvW4BDlvu1O/i57fT4zbVyLw7xOEcxq4xqvxVr6zDBeZ7ueJ4k83zHb+PxNQ MHTxCRLUMBncinXAP92/0RrcqumcBNhsW4Fq28Qo2ftrnnOwrkoqyqrMiNO5FoxyUW4G LDd08YoZcL9yRWSv0m0ZxWRUZwVXzdjeAbCLxfhW5YFTdmrGy8v+C/3ni/uL6Lnv29cN RQqL6XIXCqBBo82MkP0YPSBGd8rJVXmbb25OWTtIMS2rgJEpEN/KX9n8YlTplW7XVbP8 YA7w== X-Gm-Message-State: AGRZ1gJosMhsSbWk7mnHvX39wFtySXOgPqVaOniMpZ6Y4vpro0lKRIkL bFY+NwSkDnIQK16SIuDVClEwxiS0Z/3rYA== X-Google-Smtp-Source: AJdET5c6605IV75wjzyJfxwq7F3ukh6iDLi8X/0ziwAaNlXurli30gz6wVZaufYyP7c7ypTHg4dmDQ== X-Received: by 2002:a63:4d0e:: with SMTP id a14mr3734023pgb.408.1541752164979; Fri, 09 Nov 2018 00:29:24 -0800 (PST) Received: from [192.168.0.110] ([183.182.110.3]) by smtp.gmail.com with ESMTPSA id r81-v6sm10875794pfa.110.2018.11.09.00.29.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Nov 2018 00:29:24 -0800 (PST) References: <87tvktjfq3.wl-jch@irif.fr> Mime-Version: 1.0 (1.0) In-Reply-To: <87tvktjfq3.wl-jch@irif.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1E65766B-72D2-4826-A9F7-AD226FE6E242@gmail.com> Cc: babel@ietf.org X-Mailer: iPad Mail (13G36) From: Mahesh Jethanandani Date: Fri, 9 Nov 2018 15:29:22 +0700 To: Juliusz Chroboczek Archived-At: Subject: Re: [babel] Information model and YANG: about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 08:29:27 -0000 Hi Juliusz, My comments inline. > On Nov 7, 2018, at 6:21 PM, Juliusz Chroboczek wrote: >=20 > My comment during the meeting, expanded. >=20 > HMAC does not carry keys or algorithm identifiers on the wire: algorithm > and key are provisioned by means outside of the Babel protocol (currently > a configuration file, That is correct. > but we're working on implementing key rotation at > runtime), then only the results of the HMAC computation are sent on the > wire. There are and have been several efforts to define key rotation, specially in= the now defunct KARP WG, but had a few drafts on this. Let me see if I can d= ig them up. >=20 > Hence, the base protocol does not need a registry of HMAC algorithm > identifiers: the only place where HMAC algorithms appear is the config > file, and how they are expressed there is purely a local implementation > decision. I am not clear on what you mean by "expressed". I would agree that the HMAC a= lgorithm is something that has to be expressed in YANG for configuration pur= poses, and also that it be the same for the two ends of the link. >=20 > What the information model and YANG do is, among other things, to export > the configuration in an interoperable format. Hence, if we need to export= > the HMAC keys, we'll need a registry of HMAC protocols. The "interoperable" format is the YANG model. There are models that define k= eychain, and even define some of the HMAC protocols. >=20 > If we do, then the initial value should probably be just one entry: > HMAC-SHA256. Great. I will look to adding it. Thanks. >=20 > -- Juliusz >=20 >=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Fri Nov 9 03:42:58 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86060130DFB for ; Fri, 9 Nov 2018 03:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3c2Zf7AvBiE for ; Fri, 9 Nov 2018 03:42:54 -0800 (PST) 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 5433E130DEB for ; Fri, 9 Nov 2018 03:42:53 -0800 (PST) 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 wA9Bgj2g031257; Fri, 9 Nov 2018 12:42:45 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DC70E62014; Fri, 9 Nov 2018 12:42:51 +0100 (CET) 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 pa_lnpXE_BIJ; Fri, 9 Nov 2018 12:42:50 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 42A8462012; Fri, 9 Nov 2018 12:42:49 +0100 (CET) Date: Fri, 09 Nov 2018 12:42:49 +0100 Message-ID: <87in165veu.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: Babel at IETF , Antonin =?ISO-8859-1?Q?D=E9cimo?= In-Reply-To: <877ehnru8p.fsf@taht.net> References: <877ehnru8p.fsf@taht.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]); Fri, 09 Nov 2018 12:42:46 +0100 (CET) X-Miltered: at korolev with ID 5BE572B5.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BE572B5.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 : 5BE572B5.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] WG Last Call for 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: Fri, 09 Nov 2018 11:42:56 -0000 >> This message begins a Working Group Last Call for >> draft-ietf-babel-dtls-01 running through November 26th. Please >> indicate whether you think this draft is ready for publication as an >> RFC. Comments on the draft are also welcome. > Is there more than one public implementation at this point? I think there's actually none right now -- Antonin's code does not comply with the latest draft (it sends IHUs in the clear, and accepts unprotected IHUs), while David's code is lost for posterity. We (Antonin, David and me) have spent a lot of time last summer exploring the design space, so I'm not particularly concerned, but I agree we should make at least one compliant implementation publicly available. -- Juliusz From nobody Fri Nov 9 20:17:20 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F01130E07; Fri, 9 Nov 2018 20:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO97yvLbuiGC; Fri, 9 Nov 2018 20:17:18 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0: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 0AB09128D0C; Fri, 9 Nov 2018 20:17:18 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id a205-v6so312735itd.4; Fri, 09 Nov 2018 20:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=AQF07CAvnJyWOhVeoBKwgL7wudU1Xs7m292GVxZ9fto=; b=P2GU96DbTrxaMjmvsbXvh3jKAFgsUiPijPEO1Ge2SF+GcPJHY40IjIb3/AULADwfhL hP1gS8+JzqKgarCNXPkr7621ApnMaQopQd1AyrElEKYulxn3H4X9anquABcdRTm0rPe3 GcysYletNr0OrknvCT52TbI7pq0v2FGaOD45iVQXD7Rbrjl3p/fjoMvQqSEpelUtA0t4 itudjGPo+EkeoXJ9hqhhL5a6W+6w2tsqL6+iUwEkALbrEqKnQRUEDsUS/FE9XFWjtP4H iitCuyqhJPkM1E8QCWNp6CbernoXXJdO5g4QnLtdanLFcMEM6sHTTgfMPNob/KPgKe0t 3O2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=AQF07CAvnJyWOhVeoBKwgL7wudU1Xs7m292GVxZ9fto=; b=bxPGu1iK2vugY5UNUCMSNZKWiOGlGOZA3eHvkUIFJkGoIsMAKOgM0m0VPCgevB+bFd QK4c8BFCLpQIenFkTu0I9j2DRGZRThzIp5Ynn8Dko0iMi5xALRPf7d+e1f6oB8mutdVs OrZKXzP01SVn1EU3robHn0NRsU74ph0lfX2zyawjyDsIQBij6vYlqfaTOcte+9JL03me 6aBVEKHfp2eG9pQH7SSMzvDsN70EsT6Uqcj09OBtH68ij2q1/nd1E3ygCpvhLBlsVMHW 3JCBs6RbFWcA+lg0smvMW63HJGtC0xCYbzPyp7KCC7RIjVGaOXquCtw/qr2ewDd5nHjf vmnA== X-Gm-Message-State: AGRZ1gL275201phSUA5vc4h9+XzalcDd+FnbnrtqygJfwhnlWMYpfMtt yOeIsicek+0VZJuRvUnutjwLMoIey4YQvazR5GXOnpjW X-Google-Smtp-Source: AJdET5dMRFFz/ZS3aOKTfz9ud/XPyvxYstvY5yHePCq89sUzRCFCb1A+9bs6ii1rYyXa0kLEp6v687MImkYlLtD5Wxg= X-Received: by 2002:a24:39d8:: with SMTP id l207-v6mr4387496ita.103.1541823436893; Fri, 09 Nov 2018 20:17:16 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Fri, 9 Nov 2018 23:17:05 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="00000000000043352a057a47be84" Archived-At: Subject: [babel] rfc6126bis security implementation requirements 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 Nov 2018 04:17:19 -0000 --00000000000043352a057a47be84 Content-Type: text/plain; charset="UTF-8" In discussion at the BABEL WG meeting in Bangkok, there appeared to be consensus in the room that rfc6126bis should normatively reference both the hmac and the dtls Babel security drafts and should recommend implementing both. It should also recommend using hmac unless the additional security features of dtls are specifically needed. Neither would be mandatory to implement. This email is to confirm that consensus. If you have any opinion on this, please reply within the next week or two. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com --00000000000043352a057a47be84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In discussion at the BABEL WG meeting in Bangkok, there ap= peared to be consensus in the room that rfc6126bis should normatively refer= ence both the hmac and the dtls Babel security drafts and should recommend = implementing both. It should also recommend using hmac unless the additiona= l security features of dtls are specifically needed. Neither would be manda= tory to implement. This email is to confirm that consensus.

<= div>If you have any opinion on this, please reply within the next week or t= wo.

Thanks,
Donald
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2= =A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com
<= /div> --00000000000043352a057a47be84-- From nobody Sat Nov 10 01:21:38 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA61130E11; Sat, 10 Nov 2018 01:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdxRYCMLdU-Y; Sat, 10 Nov 2018 01:21:35 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2371E130DE4; Sat, 10 Nov 2018 01:21:34 -0800 (PST) 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=1541841692; bh=d4lUfGRsbIjwH2L4fuwxEDYw6JbQ0uEPhCfeONjB48M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mrEJEqYnHpLt4qKm/+A0RcXH3HqRnqhBDlQPUZ9ititQ+myVZY7bF1czx4wZa0XK5 8b4bvwFwi8F1YZQYJqifw5rCq33uNwNSWOPw05M5Et/9ySp4kt1TYnz1jccTWek32F IvN5uKQY/Oj5rbva2ubvKAUz/Ue68fBsUB8Wnn5cDJx0wekCDwCdSntCswE6dyqcXS jbmyHMKJS9AQWrM8g7F44w394rXi1g+qbg6AjjqrG4NUeHyjjbBnhk/PX9Sg95P+rH LC6TLB6WkzMoXJo15QK+n3rIWdqVXDosOXgvm3ca+HmiZmXdpYk6v00xLhxYrVjG2V kC7AJ7liY5bVw== To: Donald Eastlake , Babel at IETF Cc: babel-chairs In-Reply-To: References: Date: Sat, 10 Nov 2018 10:21:24 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87pnvdjnjf.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] rfc6126bis security implementation requirements 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 Nov 2018 09:21:38 -0000 Donald Eastlake writes: > In discussion at the BABEL WG meeting in Bangkok, there appeared to be > consensus in the room that rfc6126bis should normatively reference > both the hmac and the dtls Babel security drafts and should recommend > implementing both. It should also recommend using hmac unless the > additional security features of dtls are specifically needed. Neither > would be mandatory to implement. This email is to confirm that > consensus. Sounds good to me :) -Toke From nobody Sat Nov 10 03:56:40 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D6A130E37; Sat, 10 Nov 2018 03:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4AaiUhWqvgM; Sat, 10 Nov 2018 03:56:34 -0800 (PST) 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 8F70E127333; Sat, 10 Nov 2018 03:56:34 -0800 (PST) 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 wAABuQKG022054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 10 Nov 2018 12:56:26 +0100 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 wAABuRiZ032414; Sat, 10 Nov 2018 12:56:27 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2271E6C9DD; Sat, 10 Nov 2018 12:56:32 +0100 (CET) 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 3VpKXkTuKuSu; Sat, 10 Nov 2018 12:56:30 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id DF1586C9DB; Sat, 10 Nov 2018 12:56:29 +0100 (CET) Date: Sat, 10 Nov 2018 12:56:29 +0100 Message-ID: <87o9axrvrm.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , babel-chairs In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 10 Nov 2018 12:56:26 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 10 Nov 2018 12:56:28 +0100 (CET) X-Miltered: at korolev with ID 5BE6C76A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5BE6C76B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BE6C76A.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5BE6C76B.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 : 5BE6C76A.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5BE6C76B.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] rfc6126bis security implementation requirements 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 Nov 2018 11:56:38 -0000 > In discussion at the BABEL WG meeting in Bangkok, there appeared to be > consensus in the room that rfc6126bis should normatively reference both the > hmac and the dtls Babel security drafts and should recommend implementing both. > It should also recommend using hmac unless the additional security features of > dtls are specifically needed. Neither would be mandatory to implement. This > email is to confirm that consensus. I think that what we agreed about is that Babel-HMAC is recommended, both for implementation and deployment, and that we (as a group) hold no opinion on Babel-DTLS. The reason we don't want to recommend implementing Babel-DTLS is that it is not necessarily trivial to implement: it requires a fair amount of hacking to get an implementation to speak unicast, and it imposes a dependency on a DTLS stack. Thus, I think that recommending implementation of Babel-DTLS might reduce the applicability of Babel. Let's recommend Babel-HMAC, and let the market choose whether to implement Babel-DTLS. -- Juliusz From nobody Sun Nov 11 00:37:43 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93A212DDA3; Sun, 11 Nov 2018 00:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhsB2kX6SCAV; Sun, 11 Nov 2018 00:37:40 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0: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 387821200D7; Sun, 11 Nov 2018 00:37:40 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id m34-v6so8664831iti.1; Sun, 11 Nov 2018 00:37:40 -0800 (PST) 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=dnmQKOy89a8Ekw1Elrb4KnhydF2lSjXvN6joEylRjUc=; b=OZFDvmgyZ9vn8eGpVKHFaUDpWwx0uALTvhaP7HnxwaAibq81mJAD1Wuh5MoarftU1+ 3A/bqQiUDsV9mChUBGIvadgZRvN3spz7YB8YqzG4/bPV4ih1QVo1BaSioegMdasTBpPl rEnZQJKUPfzH2c1kdyJrpcFLE0jhYnXAL27mqRF0LftBHaEGGRfLornsz+KNO/sejHU0 5zv2+udhQxvX4ugnG7TNFdVv1TNPAki9R3sPS4CM1cD6YKh8KdAhgV4dDCgdvuu2haLp ZlXwSFrSGXbxM+h/o91w4R2KW8gjuhNhAILM0YJnZzFbLeXPya58ocsKUDWG7zyFhV9O 8hCQ== 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=dnmQKOy89a8Ekw1Elrb4KnhydF2lSjXvN6joEylRjUc=; b=RcusFWkts5xomopMGF8C7hMIL5p+tFTn6mcGlYOlFbbeyOI4olb4+ISM7vuA3TXM/G Pys2Y/9YdB6xjrb0kw+hLgplTxMcGT59+WjB5uC4QPFsGsYWTZtgn0Za0V03C6DtCcHR U7EPamsK9ckf/eLWnMTbjk0a2b4xmf5k9XkFK90qXxFDW+xSgLTVWP8YXQ0nMULo0vyX 2e8wRSesrmb1WLNddeButNyVvVVHUkxK5N3s/3kO5CvG2fjhlB8ZFOCV+r7optI6VnwI Jr6AvLaFp7zBpui6BcIKkDmUnfQd7Yv0N8z8zDkRfuX112vAyYRwNN81ziHpVSPa9Byz Kcgg== X-Gm-Message-State: AGRZ1gLoy1bwpej13wVp7W0spqW0IiHLtxt2vXHrJB11V4pKA8i9y+Zb Bn/Sw3fKeyEJlRn/FFdY+Bxy41f9efSA4fNvlRU= X-Google-Smtp-Source: AJdET5eNzAtvzXBbND6h2m9JBGPm+zniBWJIT5uN1Eq1noboITKu/T9SxOvkiqj/CJ83ro3PFpuimVd2nmWKouViHcI= X-Received: by 2002:a24:bc47:: with SMTP id n68-v6mr8548782ite.102.1541925459281; Sun, 11 Nov 2018 00:37:39 -0800 (PST) MIME-Version: 1.0 References: <87o9axrvrm.wl-jch@irif.fr> In-Reply-To: <87o9axrvrm.wl-jch@irif.fr> From: Donald Eastlake Date: Sun, 11 Nov 2018 03:37:27 -0500 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , babel-chairs Content-Type: multipart/alternative; boundary="000000000000454c68057a5f7f42" Archived-At: Subject: Re: [babel] rfc6126bis security implementation requirements 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, 11 Nov 2018 08:37:42 -0000 --000000000000454c68057a5f7f42 Content-Type: text/plain; charset="UTF-8" Hi Juliusz, A recommendation can be pretty weak depending on what you say about when it might not be applicable. Let's see if anyone else has comments on this. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Sat, Nov 10, 2018 at 6:56 AM Juliusz Chroboczek wrote: > > In discussion at the BABEL WG meeting in Bangkok, there appeared to be > > consensus in the room that rfc6126bis should normatively reference both > the > > hmac and the dtls Babel security drafts and should recommend > implementing both. > > It should also recommend using hmac unless the additional security > features of > > dtls are specifically needed. Neither would be mandatory to implement. > This > > email is to confirm that consensus. > > I think that what we agreed about is that Babel-HMAC is recommended, both > for implementation and deployment, and that we (as a group) hold no > opinion on Babel-DTLS. > > The reason we don't want to recommend implementing Babel-DTLS is that it > is not necessarily trivial to implement: it requires a fair amount of > hacking to get an implementation to speak unicast, and it imposes > a dependency on a DTLS stack. > > Thus, I think that recommending implementation of Babel-DTLS might reduce > the applicability of Babel. Let's recommend Babel-HMAC, and let the > market choose whether to implement Babel-DTLS. > > -- Juliusz > --000000000000454c68057a5f7f42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

A recommendation can be pre= tty weak depending on what you say about when it might not be applicable. L= et's see if anyone else has comments on this.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. East= lake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenp= ort, FL 33896 USA
=C2=A0d3e3e3@gmail.com


On Sat, Nov 10, 2018 at 6:56 AM Juliusz Chrobocz= ek <jch@irif.fr> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> In discussion at the BABEL WG meeting in= Bangkok, there appeared to be
> consensus in the room that rfc6126bis should normatively reference bot= h the
> hmac and the dtls Babel security drafts and should recommend implement= ing both.
> It should also recommend using hmac unless the additional security fea= tures of
> dtls are specifically needed. Neither would be mandatory to implement.= This
> email is to confirm that consensus.

I think that what we agreed about is that Babel-HMAC is recommended, both for implementation and deployment, and that we (as a group) hold no
opinion on Babel-DTLS.

The reason we don't want to recommend implementing Babel-DTLS is that i= t
is not necessarily trivial to implement: it requires a fair amount of
hacking to get an implementation to speak unicast, and it imposes
a dependency on a DTLS stack.

Thus, I think that recommending implementation of Babel-DTLS might reduce the applicability of Babel.=C2=A0 Let's recommend Babel-HMAC, and let t= he
market choose whether to implement Babel-DTLS.

-- Juliusz
--000000000000454c68057a5f7f42-- From nobody Sun Nov 11 00:41:14 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AB412DDA3; Sun, 11 Nov 2018 00:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGrOZGmS70Ey; Sun, 11 Nov 2018 00:41:11 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C261200D7; Sun, 11 Nov 2018 00:41:11 -0800 (PST) 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=1541925669; bh=BYhObIUN2Zy6Nige+98K5bJhgdoqIdHkr4W/wGPml0s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=t32w2Zw65GFFSf3vztDcGhNrOrEvoCHjdDpVAXmxIcfnvYZmTfAcrZ2s5GLMQK/ul LuTfqIRCBzICqhNde1OB9F79yK8CrWVOw1jhWzM6OyfXlL8ORq09cQzOHcN6Fh9k+z S5gnnfMqXUZC0CBzCTVhzZ+3q1UG62O0VBZzd6FYm7zDd+94G0YpyLNhR2/0QMfymQ iRi7TiBSN0V8DsoBi5alLBvCJ1jtAoVC6sjutafh+5jhVAPlMhrUJAWzMeMZnt1CxP 9wAxbFQLBPx/Gpp5cUl3rbQoDuVpV16cWjbBmQcOxdSgOLRtKy5/WTm/SJaIKPFhIk xjdGWIPHWVlAA== To: Donald Eastlake , Juliusz Chroboczek Cc: babel-chairs , Babel at IETF In-Reply-To: References: <87o9axrvrm.wl-jch@irif.fr> Date: Sun, 11 Nov 2018 09:41:04 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87in14dn1b.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] rfc6126bis security implementation requirements 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, 11 Nov 2018 08:41:13 -0000 Donald Eastlake writes: > Hi Juliusz, > > A recommendation can be pretty weak depending on what you say about > when it might not be applicable. Let's see if anyone else has comments > on this. Well for my part, I read "recommend both" as "great, I can continue to not implement DTLS". :) Don't have any strong opinion on the wording, though... -Toke From nobody Sun Nov 11 03:46:43 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF2127332; Sun, 11 Nov 2018 03:46:41 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 1ev0sEkJFkoO; Sun, 11 Nov 2018 03:46:40 -0800 (PST) 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 39B5D1200D7; Sun, 11 Nov 2018 03:46:40 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 21476B93; Sun, 11 Nov 2018 06:46:39 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 11 Nov 2018 06:46:39 -0500 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=fm1; bh=i//2OuMzFWcx3t4bANeNlddZZeSC/dobDWIzg7zth kQ=; b=DQsFp14Mr1RCfopnKvILnjHYUHFgOW7yzytQXvjZTylKX9TuUeKlyalxQ zMJTs71Y4m1n6NvaSovwSF9WtDgRBKCTGbcSnPgGxi+FcCxNludpnOkrOQv8o0BJ iVfk3CQKj813SVdZkKz2mWTwCqxwlpGcZWfkaqjNpbAwHmDj6jRKbeUqshNZze98 4HsF4znK9ms/YqurNOZTxviLq7CcAt24t3A/xK3gYhJFlw1znrJMYjOZqQoIvsuK yT1aHb2QXboIJtnlHyicuoKeKaSM72r7eqNhB3zSVtGtlWRm7AkmQCHNuTlGhgtS /cJbQB/YxXytFJVKhRdrbkJlBKWmQ== X-ME-Sender: X-ME-Proxy: Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net [162.229.180.77]) by mail.messagingengine.com (Postfix) with ESMTPA id D0C6DE476E; Sun, 11 Nov 2018 06:46:37 -0500 (EST) From: "Russ White" To: "'Donald Eastlake'" , "'Juliusz Chroboczek'" Cc: "'Babel at IETF'" , "'babel-chairs'" References: <87o9axrvrm.wl-jch@irif.fr> In-Reply-To: Date: Sun, 11 Nov 2018 06:46:36 -0500 Message-ID: <008f01d479b4$34a63910$9df2ab30$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFfN3/DqudInc7jKiwQE3NLM1WwPgJweklSAUmHXhqmFyjqUA== Content-Language: en-us Archived-At: Subject: Re: [babel] rfc6126bis security implementation requirements 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, 11 Nov 2018 11:46:42 -0000 > A recommendation can be pretty weak depending on what you say about > when it might not be applicable. Let's see if anyone else has comments = on > this. If we need to mention something, then I would make it a "MAY," so that = folks know it's out there. It might be worth building an appendix = someplace explaining why this is difficult? =F0=9F=98=8A /r From nobody Wed Nov 14 08:42:21 2018 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EECF6130DD7; Wed, 14 Nov 2018 08:42:09 -0800 (PST) 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.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <154221372992.19234.5940745767377063098@ietfa.amsl.com> Date: Wed, 14 Nov 2018 08:42:09 -0800 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-hmac-01.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, 14 Nov 2018 16:42:10 -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-01.txt Pages : 16 Date : 2018-11-14 Abstract: This document describes a cryptographic authentication for the Babel routing protocol that has provisions for replay avoidance. This document updates RFC 6126bis and obsoletes RFC 7298. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-hmac-01 https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-hmac-01 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 Wed Nov 14 08:59:18 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F0E128D09 for ; Wed, 14 Nov 2018 08:59:16 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 tWU9_dovlsJ3 for ; Wed, 14 Nov 2018 08:59:14 -0800 (PST) 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 E404B130DE4 for ; Wed, 14 Nov 2018 08:59:13 -0800 (PST) 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 wAEGx5fh024240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 14 Nov 2018 17:59:05 +0100 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 wAEGx7x2008243 for ; Wed, 14 Nov 2018 17:59:07 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 004162B4DB for ; Wed, 14 Nov 2018 17:59:11 +0100 (CET) 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 GM6UGGEQs0aE for ; Wed, 14 Nov 2018 17:59:08 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 506C82B4D7 for ; Wed, 14 Nov 2018 17:59:08 +0100 (CET) Date: Wed, 14 Nov 2018 17:59:08 +0100 Message-ID: <87lg5vtx2b.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org In-Reply-To: <154221372992.19234.5940745767377063098@ietfa.amsl.com> References: <154221372992.19234.5940745767377063098@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]); Wed, 14 Nov 2018 17:59:05 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 14 Nov 2018 17:59:07 +0100 (CET) X-Miltered: at korolev with ID 5BEC5459.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5BEC545B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BEC5459.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5BEC545B.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 : 5BEC5459.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5BEC545B.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] I-D Action: draft-ietf-babel-hmac-01.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: Wed, 14 Nov 2018 16:59:16 -0000 > https://tools.ietf.org/html/draft-ietf-babel-hmac-01 > https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-01 Dear all, Weronika and I have spent most of the afternoon writing the Security Considerations section that has been added in this revision. We'll be grateful for a review. Thanks, -- Juliusz From nobody Wed Nov 14 09:18:44 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD33130E7D for ; Wed, 14 Nov 2018 09:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1CKzg0TZ6DJ for ; Wed, 14 Nov 2018 09:18:39 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6707F130DE4 for ; Wed, 14 Nov 2018 09:18:39 -0800 (PST) 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=1542215916; bh=s3XyiTI9BRbgKtewZygdI1dyQFtxx1ifZw6fg68R898=; h=From:To:Subject:In-Reply-To:References:Date:From; b=x8J2Z5Fmr2oQFfGhCE/Z+hqdBNT6I846NNLei2CiFfpjGAkAjQt0wPVX9z/xLyjjE GSpAwmbY1XLfOQhO81ybG5Q578PxD3KaEjh0qWqpZSmLb87XlMtAPr88U/CSEfF2n1 5qwHt+QzUEk280ZMK09B4pDGYklc1E1it3kItbCKUYgrAlCv1pYFWCmw/NYNHRVKMR a0x99TxVhShwbj4+LtaNpLvroS5WtiIjlLXw1/JrRdU8Obw+FzOE2RPmP0xx4M2eGN iJGe1R97JBx7WUKfboyPLyysNYYpt8YMA4a0suK9VfRD6Zjxb68wGJvw4L20NqExN4 HUJ7VkZP3bnUg== To: Juliusz Chroboczek , babel@ietf.org In-Reply-To: <87lg5vtx2b.wl-jch@irif.fr> References: <154221372992.19234.5940745767377063098@ietfa.amsl.com> <87lg5vtx2b.wl-jch@irif.fr> Date: Wed, 14 Nov 2018 09:18:33 -0800 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <875zwzvaqe.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-hmac-01.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: Wed, 14 Nov 2018 17:18:42 -0000 Juliusz Chroboczek writes: >> https://tools.ietf.org/html/draft-ietf-babel-hmac-01 >> https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-01 > > Dear all, > > Weronika and I have spent most of the afternoon writing the Security > Considerations section that has been added in this revision. We'll be > grateful for a review. One thing: This sentence in the security considerations is odd: > The scope of this protocol is strictly limited: it only provides > authentication, on the assumption that routing information is not > confidential, only symmetric keying, and only allows for the use of a > small number of symmetric keys on each link. The "on the assumption that routing information is not confidential" bit breaks up the flow; suggest revising :) -Toke From nobody Wed Nov 14 09:33:36 2018 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85126130E26; Wed, 14 Nov 2018 09:33:34 -0800 (PST) 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.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <154221681449.19116.11099611681557468061@ietfa.amsl.com> Date: Wed, 14 Nov 2018 09:33:34 -0800 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-07.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 17:33:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : The Babel Routing Protocol Authors : Juliusz Chroboczek David Schinazi Filename : draft-ietf-babel-rfc6126bis-07.txt Pages : 60 Date : 2018-11-14 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 14 10:09:12 2018 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA87130DDC; Wed, 14 Nov 2018 10:09:10 -0800 (PST) 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.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <154221895078.19200.14899455968940400646@ietfa.amsl.com> Date: Wed, 14 Nov 2018 10:09:10 -0800 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-applicability-05.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 18:09:11 -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-05.txt Pages : 10 Date : 2018-11-14 Abstract: Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. In this document, we argue that there exist niches where Babel is useful and that are not adequately served by more mature protocols. The 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-babel-applicability-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-applicability-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 14 11:55:45 2018 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6B130DBE; Wed, 14 Nov 2018 11:55:43 -0800 (PST) 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.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <154222534380.19121.10488513058207750440@ietfa.amsl.com> Date: Wed, 14 Nov 2018 11:55:43 -0800 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-dtls-02.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, 14 Nov 2018 19:55:44 -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-02.txt Pages : 8 Date : 2018-11-14 Abstract: The Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This documents describes a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). This document updates RFC 6126bis. 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-babel-dtls-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 16 05:07:07 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D3D12872C for ; Fri, 16 Nov 2018 05:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHdGYAGmrnw3 for ; Fri, 16 Nov 2018 05:07:02 -0800 (PST) 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 8203312426A for ; Fri, 16 Nov 2018 05:07:02 -0800 (PST) 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 wAGD6sip029736; Fri, 16 Nov 2018 14:06:54 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6C23071B1F; Fri, 16 Nov 2018 14:07:00 +0100 (CET) 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 Qa2XGVTghHRQ; Fri, 16 Nov 2018 14:06:58 +0100 (CET) Received: from pirx.irif.fr (unknown [138.231.120.148]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 31D5871B1A; Fri, 16 Nov 2018 14:06:58 +0100 (CET) Date: Fri, 16 Nov 2018 14:06:57 +0100 Message-ID: <87va4xw4r2.wl-jch@irif.fr> From: Juliusz Chroboczek To: "Russ White" Cc: "'Babel at IETF'" In-Reply-To: <008f01d479b4$34a63910$9df2ab30$@riw.us> References: <87o9axrvrm.wl-jch@irif.fr> <008f01d479b4$34a63910$9df2ab30$@riw.us> 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, 16 Nov 2018 14:06:54 +0100 (CET) X-Miltered: at korolev with ID 5BEEC0EE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BEEC0EE.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 : 5BEEC0EE.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] rfc6126bis security implementation requirements 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 Nov 2018 13:07:06 -0000 > If we need to mention something, then I would make it a "MAY," so that > folks know it's out there. It might be worth building an appendix > someplace explaining why this is difficult? I think that David and Antonin have done a good job in the Applicability section of Babel-DTLS. I'd rather not litter 6126bis with this kind of considerations, it's grown too much already since 6126. (Please review the Applicability section of Babel-DTLS, and tell us if that's good enough.) -- Juliusz From nobody Fri Nov 16 05:18:55 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2B7130ECF for ; Fri, 16 Nov 2018 05:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72n_SJzhJG1y for ; Fri, 16 Nov 2018 05:18:52 -0800 (PST) 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 07446128BCC for ; Fri, 16 Nov 2018 05:18:51 -0800 (PST) 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 wAGDIiaw007537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Nov 2018 14:18:44 +0100 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 wAGDIkDI025273; Fri, 16 Nov 2018 14:18:46 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5516B71FC8; Fri, 16 Nov 2018 14:18:50 +0100 (CET) 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 RMWhcB2KZu0R; Fri, 16 Nov 2018 14:18:48 +0100 (CET) Received: from pirx.irif.fr (unknown [138.231.120.148]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 30C8671FC1; Fri, 16 Nov 2018 14:18:46 +0100 (CET) Date: Fri, 16 Nov 2018 14:18:46 +0100 Message-ID: <87tvkhw47d.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Babel at IETF In-Reply-To: <87in14dn1b.fsf@toke.dk> References: <87o9axrvrm.wl-jch@irif.fr> <87in14dn1b.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 16 Nov 2018 14:18:44 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 16 Nov 2018 14:18:46 +0100 (CET) X-Miltered: at korolev with ID 5BEEC3B4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5BEEC3B6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BEEC3B4.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5BEEC3B6.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 : 5BEEC3B4.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5BEEC3B6.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] rfc6126bis security implementation requirements 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 Nov 2018 13:18:54 -0000 >> A recommendation can be pretty weak depending on what you say about >> when it might not be applicable. Let's see if anyone else has comments >> on this. > Well for my part, I read "recommend both" as "great, I can continue to > not implement DTLS". :) I take this to mean that you agree with me in principle... > Don't have any strong opinion on the wording, though... ...but think I'm being overly pedantic. (You probably have a stronger expression in mind.) As to implementing Babel-DTLS or not: the bet we're making with Babel-HMAC is that people don't actually need asymmetric auth or confidentiality, and that they'll be happy enough with the deliberately minimal features provided by Babel-HMAC. I like to think of Babel-DTLS as our insurance in case we lose the bet. (David and Antonin might see things differently.) -- Juliusz From nobody Fri Nov 16 11:40:56 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9228E127598 for ; Fri, 16 Nov 2018 11:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yeUFXFr2nd7 for ; Fri, 16 Nov 2018 11:40:52 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6458F127332 for ; Fri, 16 Nov 2018 11:40:52 -0800 (PST) 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=1542397247; bh=2mZa/q5ePIct1KR6Yk6VVgbtNO1KvBZNaKgFt7A/VZ0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=p1QwFKJjgGU3W0I7v+lbGv8AvJMHKMl/P/MwkNfTXp0UC6gfMXpG9UaC7lRj8oCkT wztk2ZlLlOj7QNqrztgMihXjhq6E76mZzfHHrbtniS/j6i1K9n5JWUhbYNWedTuABP j+y1J21nblVy7jjwaXgUTlHF510XANf4QGngvTOj0jWx8HAMBL5j5u17YFR5zlegXD 2th3+uZzCylSq1zNl9K21SahsEsrO/tIE1SUd/D2tLKcUPyEXtLpx3JqAYv0E3YC49 i/tyUVNoBFqHPfNLRh0XDaab/+HG+qcRQaqnCrUKp/Ie6ooKLFQG97utI49GacnF0f 2YDruHRAEQZhw== To: Juliusz Chroboczek Cc: Babel at IETF In-Reply-To: <87tvkhw47d.wl-jch@irif.fr> References: <87o9axrvrm.wl-jch@irif.fr> <87in14dn1b.fsf@toke.dk> <87tvkhw47d.wl-jch@irif.fr> Date: Fri, 16 Nov 2018 11:29:59 -0800 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877ehcu8g8.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] rfc6126bis security implementation requirements 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 Nov 2018 19:40:55 -0000 Juliusz Chroboczek writes: >>> A recommendation can be pretty weak depending on what you say about >>> when it might not be applicable. Let's see if anyone else has comments >>> on this. > >> Well for my part, I read "recommend both" as "great, I can continue to >> not implement DTLS". :) > > I take this to mean that you agree with me in principle... Yup. >> Don't have any strong opinion on the wording, though... > > ...but think I'm being overly pedantic. (You probably have a stronger > expression in mind.) I'm fine with the text in -07. -Toke From nobody Mon Nov 26 04:43:51 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6E8126CC7 for ; Mon, 26 Nov 2018 04:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122] 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 gBRyqtWM--bN for ; Mon, 26 Nov 2018 04:43:47 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 A8F6A12D4EA for ; Mon, 26 Nov 2018 04:43:47 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id p17so17276313qtl.5 for ; Mon, 26 Nov 2018 04:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=jti0zm07ZBdSZ4EzqOL/k3n1/qx0+GHZ7qN7UkI2P0U=; b=cXrf3cgWRxH4Q0ZvJLokx0Np/r3g5DpEy4Wv3okUEeD0PLuWb/n+TCiPnaC+h7Amp8 VUPbkNRhpuz0Z/vN9Bp7V6aCfcrXaM+e0crYZ5PcNt7PobuoJBa0SXSD2ECxSHZk0QoV xGrubCDrUKGkdN1fpq+sdL+0e7OMi4FeWHjnpamImOdOTH4vmvdSXCvz/uyzcu43cWmK 2D5U32r4Py3F2sv1mE2RPckQzPqr+/5qRwgv4jDeoyv0GUTJq/T0QLj28bxbiY/yw65/ PoWHZEvTidxafmqrslqRyRBns3ozAXNXKlxSmoG2CdOXwJ05VLtHwv5LU4lf1mL9Q3Lr D2lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=jti0zm07ZBdSZ4EzqOL/k3n1/qx0+GHZ7qN7UkI2P0U=; b=KU+/Ur8VX0xjTvbGpEa9k7ReDcmkuQ0pGOOebV24n/bDEZoa15KiBj6lfo9kb9EQh/ FdQVV9Cmm3RJcDZAxh0dkQvP0ZWtraIniAc4J4hXaBRoLQIzLCBG3kJ8xchLfWoa6Jp6 pDPjqeBF2BZGLj+Ex2YkGfa+EMvvRQOAUmxWlzrUCeqCKXw8/0p9a/2YHiTH8G5Ew/Cs iLXY0TJ21wa4yw3rRXOHvJNeQ5lHu7l8tBMUiUDMp7pvR03lPr86u44r6T+jP1X4RoU/ Qe7MWXsL79pvJ74EEY8vp/w5qVvXa8fS1ptMRcxjG5WeJsTCvIoJwhdJMn9cURhy9m70 AHRw== X-Gm-Message-State: AGRZ1gIg8dPrS8MToiLRXZDToxFko/S9nFmse9e3eXbniVa2s1N18Cpm xXc1Wd9tZOKNqJFkkjdlKiUBIJ6WSy4tQQPxbKB80uf1 X-Google-Smtp-Source: AJdET5dP+EMD5ix9pXF++9Ru/1wF+IsW80TEmZ3Va83aZ+OxJqkmxWjxoLAjU53nRZLJBuG6Ijap5xZdPn3BPMbbeeM= X-Received: by 2002:ac8:3065:: with SMTP id g34mr26265208qte.136.1543236226608; Mon, 26 Nov 2018 04:43:46 -0800 (PST) MIME-Version: 1.0 From: Dave Taht Date: Mon, 26 Nov 2018 04:43:34 -0800 Message-ID: To: babel-users , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [babel] rather than ripemd160... 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 Nov 2018 12:43:49 -0000 I have been fiddling with the hmac-challenge branch and deeply unhappy at the prospect of how much cpu this may end up consuming on the cheap MIPs routers common today (which are, admittedly, rapidly being replaced by cheap ARM ones). (let's not talk about dtls) Anyway, the default hash function is sha256 in the hmac-challenge branch. I approve, there's hardware support for it, and if someone breaks it, civilization collapses, so an alternate hmac is a "good to have", and what's in that branch... is ripemd160. Both blake and siphash seem like a superior choice for an alternate hmac function to ripemd160. In particular blake is subject of its own RFC, and comes in several clean highly optimized versions for x86 and arm architectures. https://blake2.net/ - https://www.131002.net/siphash/siphash.pdf ? --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Mon Nov 26 05:06:49 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE6A12D4EA for ; Mon, 26 Nov 2018 05:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sE8v5q3r3Vef for ; Mon, 26 Nov 2018 05:06:45 -0800 (PST) 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 EFF48124408 for ; Mon, 26 Nov 2018 05:06:44 -0800 (PST) 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 wAQD6a7v002580; Mon, 26 Nov 2018 14:06:36 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7FB5063A1C; Mon, 26 Nov 2018 14:06:42 +0100 (CET) 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 e_JgaCUzQHbq; Mon, 26 Nov 2018 14:06:37 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 67E1963A10; Mon, 26 Nov 2018 14:06:37 +0100 (CET) Date: Mon, 26 Nov 2018 14:06:37 +0100 Message-ID: <87in0koun6.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: babel-users , Babel at IETF In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 26 Nov 2018 14:06:36 +0100 (CET) X-Miltered: at korolev with ID 5BFBEFDC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BFBEFDC.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 : 5BFBEFDC.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] rather than ripemd160... 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 Nov 2018 13:06:48 -0000 > Anyway, the default hash function is sha256 in the hmac-challenge > branch. I approve, there's hardware support for it, and if someone > breaks it, civilization collapses, so an alternate hmac is a "good to > have", and what's in that branch... is ripemd160. =46rom a standardisation point of view: - HMAC-SHA256 is Mandatory to Implement; - implementation may implement other MAC algorithms, and since no algorithm identifier is carried on the wire, doing that requires no further standardisation action. =46rom the point of view of the implementation, we need to clean up this code to remove the dependency on OpenSSL. When we do that, we'll probably remove the HMAC-RIPEMD160 code, and leave just SHA256. (Don't hold your breath, though -- it's exam season for both the girls and myself.) If we add another HMAC algorithm, we'll want to do it in agreement with Toke, so that both implementations implement the same set of HMAC algorithm= s. > Both blake and siphash seem like a superior choice for an alternate hmac > function to ripemd160. In particular blake is subject of its own RFC, > and comes in several clean highly optimized versions for x86 and arm > architectures. I hold no opinion on that at the current time, I'd need to consult my colleagues. -- Juliusz From nobody Mon Nov 26 05:24:14 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EFE130DEC for ; Mon, 26 Nov 2018 05:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFKGAG85mvhs for ; Mon, 26 Nov 2018 05:24:10 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD1412D4ED for ; Mon, 26 Nov 2018 05:24:09 -0800 (PST) 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=1543238647; bh=/XFf+65ztvuNCiKelkImrBo0u5VtSkkMWsNDlqzke78=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JyTdl9d2wolp2l91DL/ynGHQUXJxOZBYAZIMrBHnawVd3YDS+BCp/hrqMoBflA5iJ sDQXQzYVJrPgmN8AyL4w1Irq6jzLBMvT5QDoI9TYsKD6IdhDibvCNKIj1S3nT2NvWj lW+8XWXOGTe+JqJzBxrU2jLueiFRPbzsIp8przLOrkZ4z3iEh6p/xalgqRMt7CLKVd 002SCM4vciDcgr6BhANuUhZH6ZqvPy583aQsWGoSydg76SQ1LQEDvZAn4JuvwFDFBn Kvo2iAyAAtQV+QvqI0cszWAT8dKHWn4dDlbhRrKQztE6ZWvqhfz8QLFQcp02ow/Tqd /w12Yep4S5rlw== To: Juliusz Chroboczek , Dave Taht Cc: babel-users , Babel at IETF In-Reply-To: <87in0koun6.wl-jch@irif.fr> References: <87in0koun6.wl-jch@irif.fr> Date: Mon, 26 Nov 2018 14:24:07 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87in0kx98o.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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 Nov 2018 13:24:13 -0000 Juliusz Chroboczek writes: >> Anyway, the default hash function is sha256 in the hmac-challenge >> branch. I approve, there's hardware support for it, and if someone >> breaks it, civilization collapses, so an alternate hmac is a "good to >> have", and what's in that branch... is ripemd160. > > From a standardisation point of view: > > - HMAC-SHA256 is Mandatory to Implement; > - implementation may implement other MAC algorithms, and since no > algorithm identifier is carried on the wire, doing that requires no > further standardisation action. > > From the point of view of the implementation, we need to clean up this > code to remove the dependency on OpenSSL. When we do that, we'll probably > remove the HMAC-RIPEMD160 code, and leave just SHA256. (Don't hold your > breath, though -- it's exam season for both the girls and myself.) > > If we add another HMAC algorithm, we'll want to do it in agreement > with Toke, so that both implementations implement the same set of HMAC > algorithms. Bird already supports HMAC using MD5, SHA1, SHA256, SHA384 and SHA512, which is inherited by the Babel implementation. I am planning to add blake2s to that when I get around to revising the HMAC patch (see below). >> Both blake and siphash seem like a superior choice for an alternate hmac >> function to ripemd160. In particular blake is subject of its own RFC, >> and comes in several clean highly optimized versions for x86 and arm >> architectures. > > I hold no opinion on that at the current time, I'd need to consult my > colleagues. I happen to share Dave's concern about sha256. And basically all the crypto people I've been talking to have been of the opinion that blake2s is the way to go for low-powered devices. So I am definitely planning to add an implementation of that to Bird, and may even make it the default for Babel. I'm not sure if we *can* make it MTI in the spec as well (does it need to be defined by a standards track RFC for us to do that?), but if we can, I think we should seriously consider it... -Toke From nobody Mon Nov 26 05:46:38 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADB6128D68 for ; Mon, 26 Nov 2018 05:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sij3OQ8ITtO9 for ; Mon, 26 Nov 2018 05:46:34 -0800 (PST) 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 F0B84126BED for ; Mon, 26 Nov 2018 05:46:33 -0800 (PST) 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 wAQDkPmj031787; Mon, 26 Nov 2018 14:46:25 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2854464461; Mon, 26 Nov 2018 14:46:32 +0100 (CET) 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 bqrqVXsDH0rX; Mon, 26 Nov 2018 14:46:25 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B93A364453; Mon, 26 Nov 2018 14:46:25 +0100 (CET) Date: Mon, 26 Nov 2018 14:46:25 +0100 Message-ID: <87a7lwossu.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel-users , Babel at IETF In-Reply-To: <87in0kx98o.fsf@toke.dk> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 26 Nov 2018 14:46:25 +0100 (CET) X-Miltered: at korolev with ID 5BFBF931.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BFBF931.003 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 : 5BFBF931.003 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 and MTI [was: rather than ripemd160...] 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 Nov 2018 13:46:36 -0000 > I'm not sure if we *can* make [blake2s] MTI in the spec as well (does it > need to be defined by a standards track RFC for us to do that?), but if > we can, I think we should seriously consider it... Opinions? From nobody Mon Nov 26 05:46:53 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0874130DC9 for ; Mon, 26 Nov 2018 05:46:51 -0800 (PST) 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_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 u9Yxzhxj2jS9 for ; Mon, 26 Nov 2018 05:46:49 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 6CC8D126BED for ; Mon, 26 Nov 2018 05:46:49 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id r14so17530838qtp.1 for ; Mon, 26 Nov 2018 05:46:49 -0800 (PST) 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=78vtr3Y6R4zIe6gzMk8WGCQJyn0I/F+UULX86TtXhh4=; b=GilmRJr/G+O56hnavqRshEFPRQtpQg1dIaXPF63kcf5J+pIaHYRQdIUZ5XLzve2t/U 7n5mn6LeDl7c2NeRZtHpCcSr459Q4zpgUq9gbSoTsTixIMAFhQ14IbS1G1LWNi96cwxC i908Rcpge2kUQ7CGVLeQDl23Ax75srg1P3GUHXfwRxczDC01SqL3Ml5FxzxwM0CrdZPI Yt3jF34aL+j6vtSV9KS9AbkchkvDV3lm3FtPSBLDR8DTkcpqMcksY8icSQCzf4eB7ZCJ cCMRjpGu4EmGIM/kGrECbTtr5PpYXv+M3fXQi/8v2rUZWFoOzcxHkinLhkP7puUI1tlv v73A== 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=78vtr3Y6R4zIe6gzMk8WGCQJyn0I/F+UULX86TtXhh4=; b=adb6uAuDKcu5LKyr1O+bNoN557SpFzRxQkI5ynUP24Mvo1w4Bz4KapJkegSn1eTBC3 mefyV0pfc11Zolm9sPvc4JAdhNpDbx8pModGFBoW0OAwvpz7fKbkLrTi55JL+UDxFW84 XAREv/75s2vjTZvVSvpig+zFPdUvB59xuoE/x0fUH3zMbvAjYB6D21O3SCZCoBaInASS j+ucTAHOBLs+vRkSkQoeCY4Sfwq6Zv4NgHkSFGitlOsa1PV/ok52Ilf5MKUaiMuF4YEe 4qE4XRefnsrUiAB9hhVxMQy4pQ2vKUBuSQz5M0GFfRXy0/0IbYebMDaH2yOtSrZSJ9TH rWlA== X-Gm-Message-State: AGRZ1gJSaKu5lrWQT+YdNzx6+CrixEvcBiDmhh4HgHtf+BSuIZaJtLJJ 7jKkB04Jd9qBU0grQXJecm54Pv/4gHdSVToTn1EA1PSV X-Google-Smtp-Source: AJdET5e1qdkA7gG5yMKOcPTRw5d3QIuCpgnpNI3XNmXtQcZQpM0CHFSmYCwPDPDMFQBGom95QG7mwm43GpXuaI7muBk= X-Received: by 2002:ac8:326a:: with SMTP id y39mr26322282qta.175.1543240008261; Mon, 26 Nov 2018 05:46:48 -0800 (PST) MIME-Version: 1.0 References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> In-Reply-To: <87in0kx98o.fsf@toke.dk> From: Dave Taht Date: Mon, 26 Nov 2018 05:46:36 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Juliusz Chroboczek , babel-users , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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 Nov 2018 13:46:52 -0000 On Mon, Nov 26, 2018 at 5:24 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Juliusz Chroboczek writes: > > >> Anyway, the default hash function is sha256 in the hmac-challenge > >> branch. I approve, there's hardware support for it, and if someone > >> breaks it, civilization collapses, so an alternate hmac is a "good to > >> have", and what's in that branch... is ripemd160. > > > > From a standardisation point of view: > > > > - HMAC-SHA256 is Mandatory to Implement; > > - implementation may implement other MAC algorithms, and since no > > algorithm identifier is carried on the wire, doing that requires no > > further standardisation action. > > > > From the point of view of the implementation, we need to clean up this > > code to remove the dependency on OpenSSL. When we do that, we'll proba= bly > > remove the HMAC-RIPEMD160 code, and leave just SHA256. (Don't hold you= r > > breath, though -- it's exam season for both the girls and myself.) > > > > If we add another HMAC algorithm, we'll want to do it in agreement > > with Toke, so that both implementations implement the same set of HMAC > > algorithms. > > Bird already supports HMAC using MD5, SHA1, SHA256, SHA384 and SHA512, > which is inherited by the Babel implementation. I am planning to add > blake2s to that when I get around to revising the HMAC patch (see > below). > > >> Both blake and siphash seem like a superior choice for an alternate hm= ac > >> function to ripemd160. In particular blake is subject of its own RFC, > >> and comes in several clean highly optimized versions for x86 and arm > >> architectures. > > > > I hold no opinion on that at the current time, I'd need to consult my > > colleagues. > > I happen to share Dave's concern about sha256. And basically all the > crypto people I've been talking to have been of the opinion that blake2s > is the way to go for low-powered devices. So I am definitely planning to > add an implementation of that to Bird, and may even make it the default > for Babel. Well, I'd like to benchmark blake2b some also. The trendline IS towards 64bits and mips is dying... What's their definition of "low powered"? While blake2s is claimed to work on 8 bit boxes, I don't see any of those on the internet. I certainly see (as examples) the esp32 (https://en.wikipedia.org/wiki/ESP32) as something that would be cool to run babel on. (that one claims sha2 accelleration also). > > I'm not sure if we *can* make it MTI in the spec as well (does it need I'd like two hmacs to be MTI. As for the default... benchmarks on cheap hardware are needed. > to be defined by a standards track RFC for us to do that?), but if we > can, I think we should seriously consider it... I like having a backup plan so that in the rubble of civilization for sha256's breakage, we can at least route packets. https://tools.ietf.org/html/rfc7693 is informational. Is that good enough? > > -Toke --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Mon Nov 26 05:51:38 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BBF130DDF for ; Mon, 26 Nov 2018 05:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEvZ87W_sWWd for ; Mon, 26 Nov 2018 05:51:33 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D152128D68 for ; Mon, 26 Nov 2018 05:51:33 -0800 (PST) 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=1543240291; bh=8vAqlcKtb8Jv2z6lJIEEDwFT6YrIInyJLXUAXcHz0Mk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VSShk+wEXgnzthSqXcI2FsSWZro2rPQW961mbS3/AB/a6o82nLGLJvVtdTaQiNg4A 2JRGFD1q7Zk7a6WDaD4ecX4oDcAqa4cO9lRdv8eVXFoeQ6Rxh5UIZYxJSrjq/hXRP9 CMsBC6vqv9wL44u1bzmDOsv8Y3mG4qimhXcfhnjsTorK2b+vCNab/P25uOJy3p2vDO PY90gGbxodnNCu5SqN74B9tDclNt+vUvUcDxm4NUYyzaELttuiqtu1bNRvJnv1sXYu GEXbKjkU2M7nG5c7eH4O1lfSI8ByHAy+FtRfjsGorc+33yCG2teXXuYD1bSjqktEXl R4MbeFiY4SQKw== To: Dave Taht Cc: Juliusz Chroboczek , babel-users , Babel at IETF In-Reply-To: References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> Date: Mon, 26 Nov 2018 14:51:31 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871s78x7z0.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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 Nov 2018 13:51:36 -0000 Dave Taht writes: > https://tools.ietf.org/html/rfc7693 is informational. Is that good > enough? That's what I'm not sure about; it's neither standards track nor backed by a working group. So someone with more knowledge of IETF process than me needs to weigh in here :) -Toke From nobody Mon Nov 26 05:53:48 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26FF12D4ED for ; Mon, 26 Nov 2018 05:53:46 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=kapsi.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-qvruHiy44K for ; Mon, 26 Nov 2018 05:53:39 -0800 (PST) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B00C126BED for ; Mon, 26 Nov 2018 05:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=dC/rsQ/voQMnDM1l1IYGPGvDXfm1YjfI2oVAMDernPo=; b=R4yTGFxstcwxWqfkQ03z8ihFjw Y76skkYdwZK19nnZeotroH9ynXI95SUmNg5+i4MoNTwkTOXTYTfMAr98ooufaIfgmanmrr/+KoD9x K6Dr+5FFBw+eqnGupjJt+9S1T9UVNMWCubNUjI/5JwRxSwVeDzoKxR+MK4xc44c1q7UXZvukE+ySB mNyshS0VUyOF3E8vQ9mtBhvPx/rKJunXxMN95MCSGGAoFIydhiFhSZ66s2C+oeVsAXsRXG9uqlnhb /f8011R3kh5fnshRnnsbmP4DpjrP4eQ88Wx/8rt12kZKXFUSimk8lwUoHsrYTWmxlRHMDhDbtzzAH KINUgzIA==; Received: from [194.100.69.221] (helo=yuri.home) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gRHKQ-00057i-JV; Mon, 26 Nov 2018 15:53:34 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Markus Stenberg In-Reply-To: <87a7lwossu.wl-jch@irif.fr> Date: Mon, 26 Nov 2018 15:53:34 +0200 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , babel-users , Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <48CB71FB-9F90-45E8-9AD2-43AA257234C1@iki.fi> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <87a7lwossu.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.101.1) X-SA-Exim-Connect-IP: 194.100.69.221 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] HMAC and MTI [was: rather than ripemd160...] 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 Nov 2018 13:53:47 -0000 On 26 Nov 2018, at 15.46, Juliusz Chroboczek wrote: >> I'm not sure if we *can* make [blake2s] MTI in the spec as well (does = it >> need to be defined by a standards track RFC for us to do that?), but = if >> we can, I think we should seriously consider it... > Opinions? I like Blake (family of) hash functions so on that front +1; however, no = idea how bureaucracy works. Dave had a good point as well though, comparing -2s and -2b performance = on some set of hardware (e.g. arm, mips, intel) might be in order before = picking between the two. I am not convinced -2s is the way _forward_. = Even now most of hardware in my home is already 64bit .. -Markus= From nobody Mon Nov 26 05:59:28 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E79D128D68 for ; Mon, 26 Nov 2018 05:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyMsB1HqmxDS for ; Mon, 26 Nov 2018 05:59:23 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CA8126BED for ; Mon, 26 Nov 2018 05:59:23 -0800 (PST) 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=1543240760; bh=RVweHf16UHf3uFdwype5ycBlcIOR426WIAxdvwLW9zQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Oe0eJRHBXCBYJsE0rk4byFGLWcAgO5gb6NlsME2vGU1AaChIy2YoeIpqtl6WO91Pb WKId1DkKl19gzhQGeKbyGOkmPA7GU20soeBVMprcczDwr/wpmJ4UwGu7d4UvI7j9f6 fT1OQxz1UVVczBPrx6MkmIOrayosJZxpaGNX9/2ppdilS3SEf/lv3u8FU1Pr0gsjOg Cr3p0izdgRX98cDwSx21o9FlEobqVN+Z8/xBRdsYhXm0enFIVDmrSjnCr/uQ+IgmA/ 0d5TLhsUqWsW/2hxJi7AJEXckt5U2QMOynVef2UjAjCaz2MuaiWFnhw7W8ASm/mhVE ImtOVjHl7rktg== To: Markus Stenberg , Juliusz Chroboczek Cc: babel-users , Babel at IETF In-Reply-To: <48CB71FB-9F90-45E8-9AD2-43AA257234C1@iki.fi> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <87a7lwossu.wl-jch@irif.fr> <48CB71FB-9F90-45E8-9AD2-43AA257234C1@iki.fi> Date: Mon, 26 Nov 2018 14:59:20 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87sgzovt1j.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] HMAC and MTI [was: rather than ripemd160...] 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 Nov 2018 13:59:26 -0000 Markus Stenberg writes: > On 26 Nov 2018, at 15.46, Juliusz Chroboczek wrote: >>> I'm not sure if we *can* make [blake2s] MTI in the spec as well (does it >>> need to be defined by a standards track RFC for us to do that?), but if >>> we can, I think we should seriously consider it... >> Opinions? > > I like Blake (family of) hash functions so on that front +1; however, > no idea how bureaucracy works. > > Dave had a good point as well though, comparing -2s and -2b > performance on some set of hardware (e.g. arm, mips, intel) might be > in order before picking between the two. I am not convinced -2s is the > way _forward_. Even now most of hardware in my home is already 64bit > .. Right, sure. I guess I can start by putting both into Bird, and we can benchmark that... -Toke From nobody Mon Nov 26 06:21:42 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4DC130E09 for ; Mon, 26 Nov 2018 06:21:41 -0800 (PST) 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_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 osTYlFKhedO1 for ; Mon, 26 Nov 2018 06:21:39 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 60CAE130E03 for ; Mon, 26 Nov 2018 06:21:39 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id d19so17646638qtq.9 for ; Mon, 26 Nov 2018 06:21:39 -0800 (PST) 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=ZyeyO7OBW/qwj9AgtDwJRlSCeebXvJHwrpBGNUNNebY=; b=ss2mRH6QvMvFppsKq+u84z06wAC7fQbFdl4g+IjhDLzYmdtGYVloFTG/YNm3VViW6/ rHNhmNj5xoxEcFCKVqKAqydp6vVDkKJb/qvTJqiv0X0YVLG2OpyAoeksxuGRDOog0z+4 FbIDFn022My9tX2diZoLSIg7kTqpeDhsQye0VTJDGfgPvz/Rkvh9bLA00SUOyXyHWO28 gEitFlUh1IoHPeaPgV8SmO1v3iafAJ3i+9HPMLid3Y2Xc98ZHijO6pvMi5RkkabPdscp bNQbY6O6M4t2qbn0T5tFNJTJOvZ7bhB6Oy5sPcsZ8GiP6WvzTw23M/VA3ouYJiEyP/Rv bCpg== 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=ZyeyO7OBW/qwj9AgtDwJRlSCeebXvJHwrpBGNUNNebY=; b=WfOHB60SuLwdn1ujy5K32gI2FOKVO43gPOT1kb9G3om35VQGcodMZS3WEoAaRj3DHa h2k+1qvILYHHg1bSjnsRa74mNMFKdAySYOS3l7K6Y593Gq+j08IoskC0HPCK9ep/c6Rr Kfhoawviufz2YP1D8THYDE0WrkG9FfhPZhdB7pOXKhBSOFSgrlqaOAG5IFeXsG7DkWuf DCogX8xGEruO8tuTHHTEYTPYVzs9OwlPtHKs9eZqmgxzpMRs00DKgPFa9VfuGmbVuZBa RlXFUq+sSy5VxgMDbKWeI/N+RuhQgLvx3vezgGsCqKfPxsys67/duR4HUMlhog9hpNSc 8s/g== X-Gm-Message-State: AGRZ1gKfBacyZNwfE4Z120rmLtspt4Je4Do/oeie/fOdKKHno98njpRq q1Jf9WstGrNwzwSNrYLDWCcWJ4KUQzEHxzZXkSk= X-Google-Smtp-Source: AJdET5ceqEgv9ALeGBYHz+NlZxg7JaalECNKx0w/BDIbZZlC7+ACuiTX3XLRQ5cCQ3RyyzUgaMR4ZPWEhwTpwi7n478= X-Received: by 2002:ac8:6606:: with SMTP id c6mr25979585qtp.376.1543242098138; Mon, 26 Nov 2018 06:21:38 -0800 (PST) MIME-Version: 1.0 References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> In-Reply-To: <871s78x7z0.fsf@toke.dk> From: Dave Taht Date: Mon, 26 Nov 2018 06:21:26 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Juliusz Chroboczek , babel-users , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [babel] HMAC Key rotation key format (was ripemd) 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 Nov 2018 14:21:41 -0000 To me this leaves the biggest problem remaining is key rotation. Me being me, and remembering just how hard it was to get dnssec working on systems lacking reliable time, I worry about that part. What we settled on for dnsmasq-dnssec was to write the current time to flash every day (or few hours), boot up without dnssec enabled long enough to get an ntp server... and rely on key rollover taking hours or days to *usually* get a correct result. RTCs with batteries are usually not included. that's still fragile (imagine a power failure lasting days, or a box being down for several days for repair. It happens). In the case of routing... if you don't have the correct time... and you can't get a route so you can get the correct time from ntp... then what? Do we make GPSes MTI also? Setting that aside for the moment, having a standardized file format for babel keys would be a boon and boost interoperability between bird/babel and other possible implementations. You would merely declare a key name in the main conf for bird or babel, and reference it in a separate file with a format like this: KEY START_DATE END_DATE TYPE VALUE name\wrfc3339\wrfc3339\wsha256|blake2s\wvalue https://tools.ietf.org/html/rfc3339 administrators would push out this one standard format file to routers, strongly suggesting that UTC times be used universally and that key rollover should be staged over hours or days lest connectivity be lost. Other sanity checks like ensuring there is some form of persistent and correct time on routers using authentication are also needed. alternatives might include certs and other stuff that bears drinking about. --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Mon Nov 26 07:10:57 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB09130E31 for ; Mon, 26 Nov 2018 07:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIk6FaEI3fwI for ; Mon, 26 Nov 2018 07:10:53 -0800 (PST) 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 D8A57130F18 for ; Mon, 26 Nov 2018 07:10:52 -0800 (PST) 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 wAQFAh8x011929; Mon, 26 Nov 2018 16:10:43 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7546C65BC6; Mon, 26 Nov 2018 16:10:49 +0100 (CET) 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 ufoZ9LpdYgMZ; Mon, 26 Nov 2018 16:10:43 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CC7B865BB8; Mon, 26 Nov 2018 16:10:41 +0100 (CET) Date: Mon, 26 Nov 2018 16:10:41 +0100 Message-ID: <875zwjq3gu.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , babel-users , Babel at IETF In-Reply-To: <48CB71FB-9F90-45E8-9AD2-43AA257234C1@iki.fi> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <87a7lwossu.wl-jch@irif.fr> <48CB71FB-9F90-45E8-9AD2-43AA257234C1@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 26 Nov 2018 16:10:44 +0100 (CET) X-Miltered: at korolev with ID 5BFC0CF3.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BFC0CF3.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 : 5BFC0CF3.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 and MTI [was: rather than ripemd160...] 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 Nov 2018 15:10:56 -0000 > Dave had a good point as well though, comparing -2s and -2b performance > on some set of hardware (e.g. arm, mips, intel) might be in order before > picking between the two. HMAC only protects the control traffic, not the data traffic. I'm not convinced that performance is particularly critical here. -- Juliusz From nobody Mon Nov 26 11:44:31 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C331130E1B for ; Mon, 26 Nov 2018 11:44:29 -0800 (PST) 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_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 ywGaNHcxGQz0 for ; Mon, 26 Nov 2018 11:44:26 -0800 (PST) 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 6C792130E03 for ; Mon, 26 Nov 2018 11:44:26 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id q1so7094536pfi.5 for ; Mon, 26 Nov 2018 11:44:26 -0800 (PST) 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=Ct4KMtYbxnvyIT6h4bolhKM1YOgobZ2CiQ0SjyWpd+Q=; b=UwZHPt0ikv5vM283nP8YsrDWGA3hpnQpOehzsrWdbZD5TKKzvB0LtdHTKqotRE2hVP KDFN8o5zTMpbVGYXtjJUrx0l9p4XohkMsrJ10UZzuZmWQ3GQ626IDBKF8AR+d5c9hv8U PjMEVnFtmMCWaw+qENxrrUJink48l5zWtxnXbplTa+feEC7HUArHzXaG7yBbwLJCxMoD EB+dKbrDzko4z2SEfQhsmRq5GgXaDOlZShwVw6y/C0wnuhHj50JhXMvDvjSum7XOPqmL XepMm0iYGWI2QVNWSZE2S5CvyqmeN44eY1q61X+g54oTWYGtjQMTCdGWSFNs6L1xc8Sk O67A== 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=Ct4KMtYbxnvyIT6h4bolhKM1YOgobZ2CiQ0SjyWpd+Q=; b=PgRsmLV3jnURJsMvRiIi8ZIZfAIGsv6sOUQ9J2we1DwTACmp0xv1OgW+JcVL4n7Jpr 4FhQs7Y/DvWdqW+nBB2WQMyfF5VNC1fmdbGykUFnwK0gOcwl83ofMRQ5VdHmVBnwBrXQ yP/uM+DioaUtO7EO+UnqkApfNzozr7dueiUaHn6VA16a1RLkHFtiYFPWi8l4HpshyNmF eO6LRhjYuk8AePy+W37YeByNKHlNWgdpMS+VzSTiNrhViQLXCjhSqOgCqd6CEyjYO6oh 1Tu/1RqbL2JHwkEvW7cip/gh6XulNt7zAGW5/riL4rzx4hv3JwBvaZ3ld1jF7p8NZqM8 1pVQ== X-Gm-Message-State: AGRZ1gIwb0jKaf1ZaFxNCvmsY+/DNrgCBsalJ1w/j3O2cBrsZdge2RE7 xQwsd7vcCwhfuYTG0zzVl1s= X-Google-Smtp-Source: AJdET5cqo3ONOwB21fbqACLItCkOBkk99HWjJYl5vFdA8aGi4Lt57r/lcVbELXwmcL3TcaLQApsdgw== X-Received: by 2002:a62:e30d:: with SMTP id g13mr29316482pfh.151.1543261465821; Mon, 26 Nov 2018 11:44:25 -0800 (PST) Received: from [10.33.122.207] ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id w80-v6sm1703140pfk.11.2018.11.26.11.44.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 11:44:24 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_68885BFD-1A88-4167-90F7-F597C6D16C79" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 26 Nov 2018 11:44:23 -0800 In-Reply-To: Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF , babel-users , Juliusz Chroboczek , Brian Weis , Keyur Patel To: Dave Taht References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] HMAC Key rotation key format (was ripemd) 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 Nov 2018 19:44:29 -0000 --Apple-Mail=_68885BFD-1A88-4167-90F7-F597C6D16C79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A draft that proposed pair-wise key management was proposed here = . It does not = address the question of timestamp, but is something that could be = exchanged as part of key rollover to allow routers to calculate the = delta. Including the original authors of the draft. > On Nov 26, 2018, at 6:21 AM, Dave Taht wrote: >=20 > To me this leaves the biggest problem remaining is key rotation. Me > being me, and remembering just how hard it was to get dnssec working > on systems lacking reliable time, > I worry about that part. What we settled on for dnsmasq-dnssec was to > write the current time to flash every day (or few hours), boot up > without dnssec enabled long enough to > get an ntp server... and rely on key rollover taking hours or days to > *usually* get a correct result. RTCs with batteries are usually not > included. >=20 > that's still fragile (imagine a power failure lasting days, or a box > being down for several days for repair. It happens). >=20 > In the case of routing... if you don't have the correct time... and > you can't get a route so you can get the correct time from ntp... then > what? Do we make GPSes MTI also? >=20 > Setting that aside for the moment, having a standardized file format > for babel keys would be a boon and boost interoperability between > bird/babel and other possible implementations. > You would merely declare a key name in the main conf for bird or > babel, and reference it in a separate file with a format like this: >=20 > KEY START_DATE END_DATE TYPE VALUE > name\wrfc3339\wrfc3339\wsha256|blake2s\wvalue >=20 > https://tools.ietf.org/html/rfc3339 >=20 > administrators would push out this one standard format file to > routers, strongly suggesting that UTC times be used universally and > that key rollover should be staged over hours or days lest > connectivity be lost. Other sanity checks like ensuring there is some > form of persistent and correct time on routers using authentication > are also needed. >=20 > alternatives might include certs and other stuff that bears drinking = about. >=20 >=20 >=20 >=20 > --=20 >=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_68885BFD-1A88-4167-90F7-F597C6D16C79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = draft that proposed pair-wise key management was proposed here.  It does not address the question of = timestamp, but is something that could be exchanged as part of key = rollover to allow routers to calculate the delta. Including the original = authors of the draft.

On Nov 26, 2018, at 6:21 AM, = Dave Taht <dave.taht@gmail.com> wrote:

To = me this leaves the biggest problem remaining is key rotation. Me
being me, and remembering just how hard it was to get dnssec = working
on systems lacking reliable time,
I = worry about that part. What we settled on for dnsmasq-dnssec was to
write the current time to flash every day (or few hours), = boot up
without dnssec enabled long enough to
get an ntp server... and rely on key rollover taking hours or = days to
*usually* get a correct result. RTCs with = batteries are usually not
included.

that's still fragile (imagine a power failure lasting days, = or a box
being down for several days for repair. It = happens).

In the case of routing... if you = don't have the correct time... and
you can't get a route = so you can get the correct time from ntp... then
what? Do = we make GPSes MTI also?

Setting that aside = for the moment, having a standardized file format
for = babel keys would be a boon and boost interoperability between
bird/babel and other possible implementations.
You would merely declare a key name in the main conf for bird = or
babel, and reference it in a separate file with a = format like this:

KEY  START_DATE = END_DATE TYPE VALUE
name\wrfc3339\wrfc3339\wsha256|blake2s\wvalue
https://tools.ietf.org/html/rfc3339

administrators would push out this one standard format file = to
routers, strongly suggesting that UTC times be used = universally and
that key rollover should be staged over = hours or days lest
connectivity be lost. Other sanity = checks like ensuring there is some
form of persistent and = correct time on routers using authentication
are also = needed.

alternatives might include certs = and other stuff that bears drinking about.




--

Dave T=C3=A4ht
CTO, TekLibre, = LLC
http://www.teklibre.com
Tel: = 1-831-205-9740

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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_68885BFD-1A88-4167-90F7-F597C6D16C79-- From nobody Mon Nov 26 11:48:16 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA61A12DDA3 for ; Mon, 26 Nov 2018 11:48:14 -0800 (PST) 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_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 nKSrWCLLIRSD for ; Mon, 26 Nov 2018 11:48:12 -0800 (PST) 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 D5A8C12D84C for ; Mon, 26 Nov 2018 11:48:12 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAQJli2w018507; Mon, 26 Nov 2018 14:48:11 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2p0pnxhbsk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Nov 2018 14:48:11 -0500 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 wAQJm8tu005248; Mon, 26 Nov 2018 14:48:10 -0500 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 wAQJm1xC005044; Mon, 26 Nov 2018 14:48:01 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 459B54048B3B; Mon, 26 Nov 2018 19:48:01 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30486.vci.att.com (Service) with ESMTPS id 335554014743; Mon, 26 Nov 2018 19:48:01 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.213]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0415.000; Mon, 26 Nov 2018 14:47:59 -0500 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "Dave Taht" CC: Babel at IETF , babel-users , Juliusz Chroboczek Thread-Topic: [babel] [Babel-users] rather than ripemd160... Thread-Index: AQHUhYuXkcORcGptHEWYAN9B7pTvB6ViZaAAgAABX4D//9ZMsA== Date: Mon, 26 Nov 2018 19:47:59 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> In-Reply-To: <871s78x7z0.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.228.43] 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=2018-11-26_15:, , 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=646 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811260168 Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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 Nov 2018 19:48:15 -0000 FYI. IETF policies re "downrefs" in standards track RFCs is described in https://tools.ietf.org/html/rfc3967 (and updated by https://tools.ietf.org/= html/rfc8067). In short, it's not prohibited, but careful review is required.=20 Note RFC3967 Section 2 first bullet There are a number of circumstances in which an IETF document may need to make a normative reference to a document at a lower maturity level, but such a reference conflicts with Section 4.2.4 of [RFC2026]. For example: o A standards track document may need to refer to a protocol or algorithm developed by an external body but modified, adapted, or profiled by an IETF informational RFC, for example, MD5 [RFC1321] and HMAC [RFC2104]. Note that this does not override the IETF's duty to see that the specification is indeed sufficiently clear to enable creation of interoperable implementations. Barbara > Dave Taht writes: >=20 > > https://tools.ietf.org/html/rfc7693=20 is informational. Is that good > enough? >=20 > That's what I'm not sure about; it's neither standards track nor backed b= y a > working group. So someone with more knowledge of IETF process than me > needs to weigh in here :) > -Toke >=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=3D- > 6LF6X6DzeRccquqfCJFAeSx31uwzB0oM82nApUzuPo&s=3D1QakSDy0dO0qZVEb > YiyJb6tj_NKEToWqiVanTi-rv6k&e=3D From nobody Mon Nov 26 12:59:59 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18261130DBE for ; Mon, 26 Nov 2018 12:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhvoGvQC6289 for ; Mon, 26 Nov 2018 12:59:53 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE59130DCC for ; Mon, 26 Nov 2018 12:59:48 -0800 (PST) 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=1543265983; bh=CpCU0UachM+JM8TG48qe2N/ALw8sywa9lC5bDvmBmlg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HZoKsBpszPC6HP8dzBtmVq0v51jv0VY1imD4VHJPZThB9VFB0NoCXHqb9duZeJH0p xxTT6NWu47nOl9rnZlg+RWyZ8+YUtBeQ5bsRXFtITZj5xDvLkg2ndQebVSaTgW9bCL ahMvyNWYBKMKpcIPlIvbAAK77ntuT9MPYCcorwoTe+i3d1rcGmPo3pENU27qQGfxni bUR0Z51cllSbC4uMcyYvZaXsF1FFfkROIrZizQqnYxKRQ3VA0SHtw7u8TV/9Wh/hAw /JGOiCJK0CrLBKOqkqdl2ENJKT04lMie2wdYRpz9+ixLQLJb+O6WeXLGFGEje3WthQ CNvnnAr1kLyWA== To: "STARK\, BARBARA H" , Dave Taht Cc: Babel at IETF , babel-users , Juliusz Chroboczek In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Mon, 26 Nov 2018 21:59:41 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87pnurwo5e.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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 Nov 2018 20:59:56 -0000 "STARK, BARBARA H" writes: > FYI. IETF policies re "downrefs" in standards track RFCs is described in > https://tools.ietf.org/html/rfc3967 (and updated by https://tools.ietf.org/html/rfc8067). > In short, it's not prohibited, but careful review is required. > Note RFC3967 Section 2 first bullet > > There are a number of circumstances in which an IETF document may > need to make a normative reference to a document at a lower maturity > level, but such a reference conflicts with Section 4.2.4 of > [RFC2026]. For example: > > o A standards track document may need to refer to a protocol or > algorithm developed by an external body but modified, adapted, or > profiled by an IETF informational RFC, for example, MD5 [RFC1321] > and HMAC [RFC2104]. Note that this does not override the IETF's > duty to see that the specification is indeed sufficiently clear to > enable creation of interoperable implementations. Ah, so HMAC itself is already an informational RFC? Great, let's do blake2, then! :D -Toke From nobody Mon Nov 26 13:11:02 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF10130FCF for ; Mon, 26 Nov 2018 13:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNwGgHisYNAz for ; Mon, 26 Nov 2018 13:10:58 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8756A130FC8 for ; Mon, 26 Nov 2018 13:10:58 -0800 (PST) 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=1543266657; bh=JPPS96N5kvGlrNIMPS5fg95S6h88Z0Zc9IZTYvYskFY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=v5qujEitZOreq01sbcGuXSoKtkyJcGmRKMO5I8KRrp4lO3MGQMzINPifVzoNrEByn qXpBaDjxnIIhwFnhJXPsdWsaU+goIx+uos2VhSXhkM1XZadx4ShxjtFMZOz3ST6WTQ N5Kft7/tyala1Mnbvjw42+VpyxNayvvVpOJK5evws4yR3/P370yP8u77WBOC0FdtwO CVyRgo99hX5zHGorg4xr2XsJOZYkWOcLnn8UFQvsF5P+EXUwg3kPlQm1OmyTg3IM+B 8v26BMwRc83I4srOQZygB4+EiV+kmmyWQrysl62r4br1pnH+wW2DgYvAszlYJ72GvS KgymkJeJFuIxg== To: Dave Taht Cc: Juliusz Chroboczek , babel-users , Babel at IETF In-Reply-To: References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> Date: Mon, 26 Nov 2018 22:10:56 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1kzwnmn.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] HMAC Key rotation key format (was ripemd) 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 Nov 2018 21:11:00 -0000 Dave Taht writes: > To me this leaves the biggest problem remaining is key rotation. Me > being me, and remembering just how hard it was to get dnssec working > on systems lacking reliable time, The Babel HMAC extension as currently specified does not rely on wall clock time in any way, so not really sure how a comparison to dnssec is relevant? > Setting that aside for the moment, having a standardized file format > for babel keys would be a boon and boost interoperability between > bird/babel and other possible implementations. >From the point of view of each routing daemon this would just make Babel a special snowflake. What we can do is to specify the format in the information model if a cross-implementation format is really needed (which I'm not really convinced of, either)... -Toke From nobody Mon Nov 26 14:04:11 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BB2131038 for ; Mon, 26 Nov 2018 14:04:09 -0800 (PST) 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_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 WIIbhu6T7cos for ; Mon, 26 Nov 2018 14:04:07 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 B7F2313102F for ; Mon, 26 Nov 2018 14:04:07 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id d18so19527691qto.8 for ; Mon, 26 Nov 2018 14:04:07 -0800 (PST) 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=x9bgxdI+5I14aFc9SDjSnQICifr9cf1bQWx1x31ThhY=; b=LKX3RrisnITTX55Z3nt07WJ0ykw2scGaEiP2V65j5BHMqjt/Qzzljc9/CnOXlFVZhB BEOaLuksxoJkwQOoj4sh7NfTVcpTi97GBA93INFdr5CksSZJ1DwsRrvzd+zwTH7Hr5vP 11/fHoEaInOt8ZD6QKHXfu2SV8DP2VfyWGKK5abV9yQwYDhPJsMz61NG9hfBBLLvF4Je 7rJ1ZprshvLFf8kx5NBqv1JL+YiBbT7Dhhg3UGU7dqKIEh5JJCEzG2SDs4X7O6dkAWaQ vlduYDuHGT6XGFoUzmFbMcdpRDyLbcQFQNir1LEI0LeOm48HLzqWUV7l5f0vC5f5TAW6 5YIQ== 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=x9bgxdI+5I14aFc9SDjSnQICifr9cf1bQWx1x31ThhY=; b=GuCtk3TAWoMpBcTLUDBRAfLiJcVNCoPQWwNtdKlAqUX7b6cEZVg5plFjwbCH2EvpRV 46yvSNMM8sML5pbcwqQ5/uzbB2sV6G9GHAepvIZmoCol/L6CPH7dzxR1Zds9ORPTjYZ+ RfmlqFwCQPAATRpuJfsVOoebAMWY/VYgNJ3rUckrQzyRfzX4h9PfhSd9Hye+8Z2GxDbu 1VmGJ1qfAPLgDmlqWVonxYYxzFXlENKNr9QCxGi4XqhCddC7V/zVqmfyhn+VKbgre3M7 6Ije6eg9yDY19bh22WOnDP0bZlvEGVPby4aVlkiTxFKHNgJSs0J7hsEg69/Eh4Y9RfuB zOaw== X-Gm-Message-State: AGRZ1gIvDJcVjU2GBalFhHBNLfNhNxzVgBdfAP9Uh3I8nGIge2/dHrER kmCGZtcIxfbPuchMTDfHI0+lbQ9h4KUJSBTmZp8D/q3d X-Google-Smtp-Source: AJdET5fcOSZmV2Up0ZYsqkbosIfS99ar2YxRRGbpvy5zEddbuUAV+eZDdj1LOcnlZ30slW7Nt6rD6Ym8og0WOxiCB6E= X-Received: by 2002:ac8:3065:: with SMTP id g34mr28879260qte.136.1543269846645; Mon, 26 Nov 2018 14:04:06 -0800 (PST) MIME-Version: 1.0 References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <87k1kzwnmn.fsf@toke.dk> In-Reply-To: <87k1kzwnmn.fsf@toke.dk> From: Dave Taht Date: Mon, 26 Nov 2018 14:03:53 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Juliusz Chroboczek , babel-users , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] HMAC Key rotation key format (was ripemd) 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 Nov 2018 22:04:10 -0000 On Mon, Nov 26, 2018 at 1:10 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Dave Taht writes: > > > To me this leaves the biggest problem remaining is key rotation. Me > > being me, and remembering just how hard it was to get dnssec working > > on systems lacking reliable time, > > The Babel HMAC extension as currently specified does not rely on wall > clock time in any way, so not really sure how a comparison to dnssec is > relevant? More below. Relative time is ok, too. 3000 seconds from now, start rolling over. Stop signing records with the old key as soon as everyone you can currently hear uses the new key, 6000 seconds from now, retire the old key unconditionally. > > Setting that aside for the moment, having a standardized file format > > for babel keys would be a boon and boost interoperability between > > bird/babel and other possible implementations. > > From the point of view of each routing daemon this would just make Babel > a special snowflake. ok. That leaves how to get new keys into nodes running different daemons. Anyone for IKEv2? My out of bound way is via scp and ssh. Also the present babeld cannot rewrite it's entire config file (so far as I know). I think bird can... but I don't trust it. As for the key format, I wanted a way to test keys and key rollover in the existing daemons to verify this bit would work, and also measure the cpu overhead and failure modes, like those I describe below. > What we can do is to specify the format in the information model if a > cross-implementation format is really needed (which I'm not really > convinced of, either)... To quote from 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." My key points made here are "the new key is added to *all* the nodes"... which may or may not be up over the course of days, or weeks for whatever definition of "all" you have ... "Once this is done" - how can you tell? - "and packets are accepted if they are properly signed by either of the keys" hopefully you log this ... "the old key is removed". perhaps "deprecated, no longer actively used for signing, then removed after a suitable period"? So, if you do a key rotation and X routers are offline or inaccessible at that particular time... they are going to stay inaccessible forevermore, unless rekey'd via sneakernet, climbing on trees, and other forms of manual intervention. The case where you want to immediately remove a key is in the event of a security breach. I tried to use the example of dnssec as one way key rotation (on admittedly a much bigger scale) that got done right, but the new keys were distributed a good year beforehand. https://kb.isc.org/docs/aa-00822 ... also "old and new key are sent" should be "old & new keys are used for sign= ing". ... > > -Toke --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Mon Nov 26 14:22:12 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEF913103C for ; Mon, 26 Nov 2018 14:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjzS7uTqXjrt for ; Mon, 26 Nov 2018 14:22:08 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B618130DFC for ; Mon, 26 Nov 2018 14:22:08 -0800 (PST) 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=1543270926; bh=DTVpOgj/UhHAO8yPTaTqiFUnJgk6q1MhPNQDBnbow38=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OYPrZDPNTq9jvjBnSi40DpzM4rPQ2AkJa03tTi4qQrwoB7ehg0xBTTJ/N9MfZhpNh c2PMa52LaP9/2gbvDOE1dRUv6uU0kdYZdzHTRqoIYdVijB1f5SG40+ZjVk8IJsKBXp QvSySfaErpZruOMjw806S+n5AgCmWvuH3ABKxYAFYuv2M+onYwr/pVP+4rZqscOLwt KPIVT1VnC6xl8XcwF9Veeld4XoZXLHRY8QO7q1qj22sBoZOrqBQ8Crpc4gKJhKQnbQ mxODlLoefZdbqwUa4HyWtb3ymmAHHmmhViaNSxjcnN8A8X1REvTWPbq913Ii8FstLs 9SoqDDwtTC25Q== To: Dave Taht Cc: Juliusz Chroboczek , babel-users , Babel at IETF In-Reply-To: References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <87k1kzwnmn.fsf@toke.dk> Date: Mon, 26 Nov 2018 23:22:05 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877egzwkc2.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] HMAC Key rotation key format (was ripemd) 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 Nov 2018 22:22:10 -0000 Dave Taht writes: > On Mon, Nov 26, 2018 at 1:10 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> Dave Taht writes: >> >> > To me this leaves the biggest problem remaining is key rotation. Me >> > being me, and remembering just how hard it was to get dnssec working >> > on systems lacking reliable time, >> >> The Babel HMAC extension as currently specified does not rely on wall >> clock time in any way, so not really sure how a comparison to dnssec is >> relevant? > > More below. Relative time is ok, too. 3000 seconds from now, start > rolling over. Stop signing records with the old key as soon as > everyone you can currently hear uses the new key, 6000 seconds from > now, retire the old key unconditionally. Well, you would handle this by whatever mechanism you use to configure your routers in the first place... >> > Setting that aside for the moment, having a standardized file format >> > for babel keys would be a boon and boost interoperability between >> > bird/babel and other possible implementations. >> >> From the point of view of each routing daemon this would just make Babel >> a special snowflake. > > ok. That leaves how to get new keys into nodes running different > daemons. Anyone for IKEv2? > > My out of bound way is via scp and ssh. I think Juliusz' insistence that we shouldn't reinvent key distribution is wise. See above; you need to configure the daemons in the first place anyway... > Also the present babeld cannot rewrite it's entire config file (so far > as I know). I think bird can... Yup, a 'bird reconfigure' will re-read the entire config file and apply it if it parses successfully. > but I don't trust it. Your trust issues are probably best resolved between you and your daemon ;) >> What we can do is to specify the format in the information model if a >> cross-implementation format is really needed (which I'm not really >> convinced of, either)... > > To quote from 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." > > My key points made here are "the new key is added to *all* the > nodes"... which may or may not be up over the course of days, or weeks > for whatever definition of "all" you have ... "Once this is done" - > how can you tell? - "and packets are accepted if they are properly > signed by either of the keys" hopefully you log this ... "the old key > is removed". > > perhaps "deprecated, no longer actively used for signing, then removed > after a suitable period"? Hmm, having a way to mark a key as "verify only" may be useful for simpler monitoring. But really, you *could* derive the same information from the opposite bit (track how many neighbours don't sign with the new key yet). So then it becomes more of an efficiency issue (you could save one signature on the wire during rotation). Not sure if it's worth specifying another bit in the spec for this? Or if such a configuration mode should even be in the spec at all? > So, if you do a key rotation and X routers are offline or inaccessible > at that particular time... they are going to stay inaccessible > forevermore, unless rekey'd via sneakernet, climbing on trees, and > other forms of manual intervention. Presumably your key rotation policy would take into account the outage schedules of the routers in your network? :) -Toke From nobody Tue Nov 27 13:43:14 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D38C12D7F8 for ; Tue, 27 Nov 2018 13:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtSNgChv5gIp for ; Tue, 27 Nov 2018 13:43:10 -0800 (PST) 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 900C612D4F0 for ; Tue, 27 Nov 2018 13:43:06 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id u6so16267386plm.8 for ; Tue, 27 Nov 2018 13:43:06 -0800 (PST) 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=WpWH5/ERiSiiC1ER5kVdwM4YSsO1HVjHhCDZNdaiyEw=; b=ocKJAB0aNpmv/iSYYNE6J8sajnATp3y60R4HNy7YV1/EL6aNNqjfZ1Rqensa81u24M lPCvmdaDY54zFGxXAxRio+CaxWHM69fao1Q0NGh9jsjCCrPF1st93lvpET7G/SoXYnFE haLwsXJqJRwMVwga6SFXwm0J/+doG2TXzUFNe2Wvbjr7VDnSl2OGgK6dtp3VsgxCmuOR B88PgjgSLVnIdZi8ZT5Y+HfGlDqh9NPqCsPBfSi4YEV68HCU/w42XMeGfK9brmK4VYTi 7nQSzVC366y+fk93BQQ9SxvICwN8NsQy6re8N2+uVoDw4q2PAIAcYn0IqCMcMkjBBM0s GH0Q== 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=WpWH5/ERiSiiC1ER5kVdwM4YSsO1HVjHhCDZNdaiyEw=; b=r5vu4982ITNRgKxg60jJ01SdazJGG0F7zbAJ8773WdNaWoAnat979WSsns+XMxGw9C 06tomJNrrduwlnyQMVQGjXcxmADZBH5gPMDike/Mjx+nDwNeI17uqIasK/lsgWIRpHAt aC2vQCjpGvmctD1B2YPMOy1D6l+zA3XMOxiLLu+tmQKkB5q2f6aKrec5MFC6x7CkFVKQ 3dAlc60VQxI1XTXB/Uet7L6r8RJeB8mnNQk8pHvIOLvIw3yHdL/Bqh28haKZ6ahQ7zxT wcy0jZnGk5oLmuqlSceagTrodQdzJU99PKKlnrk9Q9y+Vf1pAJwHIEqzZZFfubtkD2wV OFkQ== X-Gm-Message-State: AA+aEWaJrmrwP5l9+PkmRR8hVLpp4qnpEaHDVz2IGUAelKJFK6yJKnue RYSUqvpHMGE6GgLrmn2CoMa3CWl7nPDTetMnzFEETg== X-Google-Smtp-Source: AFSGD/UYoN6Q/sC7dKOaA0hrbOlvxBI+4ttNhfQa83/Udml4JEOqsJ1iGowUhdAT9+pGr7cKKXtgl0zykW+BtV2/nH0= X-Received: by 2002:a17:902:aa0a:: with SMTP id be10mr33653302plb.266.1543354986108; Tue, 27 Nov 2018 13:43:06 -0800 (PST) MIME-Version: 1.0 References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> In-Reply-To: <87pnurwo5e.fsf@toke.dk> From: David Schinazi Date: Tue, 27 Nov 2018 13:42:54 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Barbara Stark , Dave Taht , babel-users@lists.alioth.debian.org, babel@ietf.org Content-Type: multipart/alternative; boundary="000000000000b59c08057bac557d" Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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 Nov 2018 21:43:12 -0000 --000000000000b59c08057bac557d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I feel strongly against making anything but SHA-256 mandatory to implement. It will delay publication and not improve the interoperability story. That said, I agree that the Blake2 family is a good fit here so it would be nice to have bird and babeld support them - but they do not need to be in the spec. David On Mon, Nov 26, 2018 at 12:59 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > "STARK, BARBARA H" writes: > > > FYI. IETF policies re "downrefs" in standards track RFCs is described i= n > > https://tools.ietf.org/html/rfc3967 (and updated by > https://tools.ietf.org/html/rfc8067). > > In short, it's not prohibited, but careful review is required. > > Note RFC3967 Section 2 first bullet > > > > There are a number of circumstances in which an IETF document may > > need to make a normative reference to a document at a lower maturity > > level, but such a reference conflicts with Section 4.2.4 of > > [RFC2026]. For example: > > > > o A standards track document may need to refer to a protocol or > > algorithm developed by an external body but modified, adapted, or > > profiled by an IETF informational RFC, for example, MD5 [RFC1321] > > and HMAC [RFC2104]. Note that this does not override the IETF's > > duty to see that the specification is indeed sufficiently clear t= o > > enable creation of interoperable implementations. > > Ah, so HMAC itself is already an informational RFC? Great, let's do > blake2, then! :D > > -Toke > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users --000000000000b59c08057bac557d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I feel strongly against making anything but SHA-256 mandat= ory to implement. It will delay publication and not improve the interoperab= ility story. That said, I agree that the Blake2 family is a good fit here s= o it would be nice to have bird and babeld support them - but they do not n= eed to be in the spec.

David

On Mon, Nov 26, 2018 at 12:59 PM Toke H= =C3=B8iland-J=C3=B8rgensen <toke@toke.dk= > wrote:
"STARK, BARBAR= A H" <bs7652@at= t.com> writes:

> FYI. IETF policies re "downrefs" in standards track RFCs is = described in
> https://tools.ietf.org/html/rfc3967 (and updated by https://tools.ietf.org/html/rfc8067).
> In short, it's not prohibited, but careful review is required. > Note RFC3967 Section 2 first bullet
>
>=C2=A0 =C2=A0 There are a number of circumstances in which an IETF docu= ment may
>=C2=A0 =C2=A0 need to make a normative reference to a document at a low= er maturity
>=C2=A0 =C2=A0 level, but such a reference conflicts with Section 4.2.4 = of
>=C2=A0 =C2=A0 [RFC2026].=C2=A0 For example:
>
>=C2=A0 =C2=A0 o=C2=A0 A standards track document may need to refer to a= protocol or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm developed by an external body but = modified, adapted, or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0profiled by an IETF informational RFC, for e= xample, MD5 [RFC1321]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and HMAC [RFC2104].=C2=A0 Note that this doe= s not override the IETF's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0duty to see that the specification is indeed= sufficiently clear to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0enable creation of interoperable implementat= ions.

Ah, so HMAC itself is already an informational RFC? Great, let's do
blake2, then! :D

-Toke

_______________________________________________
Babel-users mailing list
Ba= bel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/= cgi-bin/mailman/listinfo/babel-users
--000000000000b59c08057bac557d-- From nobody Tue Nov 27 13:54:12 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66259130E1B for ; Tue, 27 Nov 2018 13:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3gRA_9vWfca for ; Tue, 27 Nov 2018 13:53:56 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 A5268130DC4 for ; Tue, 27 Nov 2018 13:53:56 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id 70so8464253pgh.8 for ; Tue, 27 Nov 2018 13:53:56 -0800 (PST) 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=VmYGdW/mL1g537ZCUgtQPJ6fTh3DFHwDQPsdwXqekHs=; b=KBxJKXdREwOBjaQfjfVPEHD2nvMByXys3bx+Gl4wUVyoVJ4vAubKRxR1eQCIxnSOcp vdMyslbQmJ7ZuQGIeaG5bB9HhVHxzqCoKDN9bM5KXjIxw+0qSp+PugbFjzLvcM9ROZr9 vU/BqfGAJAaOnMlKKIwtbFwyOyrbHi2pduo78NG3zlLSVGem/HZTsbM2tHDLm0ZjyFJm YakisnIIhFiZKHrO/Sd8y10Z3SNCt4oTd+FQvnCDLxgjV2vXXMJtaq+GP8Qzo+PvM1re ZI82vCUe+7sddmoBSQZZq/n0RXB5LUn66TGE6KXQ+1qW0rcWQ+tRDuzdXEdZNAqrmuEC eynw== 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=VmYGdW/mL1g537ZCUgtQPJ6fTh3DFHwDQPsdwXqekHs=; b=N4pNVLMEzIx4fKd5/2SaX1KTz3UBpWN3SQPTXtILMHGEXgilPABKsjQ+JLYJ0nQdyA UxGpLmn+nfQ3Q4YrxPW9s/dQtloer2Nt67OblNGpbPMNi/JP05HsctztocQrsddiBLaY 8o02eKQLkcEuEzvxWhH8Y077HwHbS5BT6JY0yh7eYeGyq9WwoZCHJ6EbOlkQwatgW7/Y MelutqSnAulJ70qdyAFNp+mRnjuKRhBDSlNhChrjPaWRnk9xeq4XiBRSMuP01jV9RkPf fGNMm1hc1ht0XToeqZT8EUBvTsuAzv6WxMVMTPHZ2nClv1Kfjy+4Ea3W3/XBUaKHdvyO VSRg== X-Gm-Message-State: AGRZ1gKJHbp6fzr5U9krxE3lOAEs+kYQ1YeV3Ql9PChGMnvERTaGmrly mGGHoWcgzT4Ub23JTcreQ0ZN5cxdcuWAAqTS5E5e71oG X-Google-Smtp-Source: AJdET5exLdWS8QMQxyGQ3w32ytqKxeMumkekMj52xJyJirquR8Hvc63OXomuwGTof/JDS7xCbnYStVzzp/LAD3Xeic4= X-Received: by 2002:a62:6ec8:: with SMTP id j191mr34641179pfc.198.1543355635739; Tue, 27 Nov 2018 13:53:55 -0800 (PST) MIME-Version: 1.0 References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <87k1kzwnmn.fsf@toke.dk> <877egzwkc2.fsf@toke.dk> In-Reply-To: <877egzwkc2.fsf@toke.dk> From: David Schinazi Date: Tue, 27 Nov 2018 13:53:44 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Dave Taht , babel@ietf.org, babel-users@lists.alioth.debian.org Content-Type: multipart/alternative; boundary="0000000000006e30b7057bac7cd3" Archived-At: Subject: Re: [babel] [Babel-users] HMAC Key rotation key format (was ripemd) 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 Nov 2018 21:54:11 -0000 --0000000000006e30b7057bac7cd3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maybe I'm misunderstanding, but I think this issue is not comparable to DNSSEC. The key difference here (no pun intended) is that you can operate Babel-HMAC with multiple keys at the same time. So your rollover becomes a simple two step process: 0) all routers are functioning with OLD_KEY configured 1) go into all routers one by one and configure them to use both OLD_KEY and NEW_KEY 2) go into all routers one by one and configure them to only use NEW_KEY 3) profit You don't need any notion of time, or any added complexity to the spec. If some of the routers are down during step (1), you get to decide whether to either wait for them to come back, or skip them and effectively disconnect them from the network based on the urgency of your key rollover. Anything beyond that becomes a key management problem that is specific to your deployment, not to the routing protocol you use. On Mon, Nov 26, 2018 at 2:22 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Dave Taht writes: > > > On Mon, Nov 26, 2018 at 1:10 PM Toke H=C3=B8iland-J=C3=B8rgensen > wrote: > >> > >> Dave Taht writes: > >> > >> > To me this leaves the biggest problem remaining is key rotation. Me > >> > being me, and remembering just how hard it was to get dnssec working > >> > on systems lacking reliable time, > >> > >> The Babel HMAC extension as currently specified does not rely on wall > >> clock time in any way, so not really sure how a comparison to dnssec i= s > >> relevant? > > > > More below. Relative time is ok, too. 3000 seconds from now, start > > rolling over. Stop signing records with the old key as soon as > > everyone you can currently hear uses the new key, 6000 seconds from > > now, retire the old key unconditionally. > > Well, you would handle this by whatever mechanism you use to configure > your routers in the first place... > > >> > Setting that aside for the moment, having a standardized file format > >> > for babel keys would be a boon and boost interoperability between > >> > bird/babel and other possible implementations. > >> > >> From the point of view of each routing daemon this would just make Bab= el > >> a special snowflake. > > > > ok. That leaves how to get new keys into nodes running different > > daemons. Anyone for IKEv2? > > > > My out of bound way is via scp and ssh. > > I think Juliusz' insistence that we shouldn't reinvent key distribution > is wise. See above; you need to configure the daemons in the first place > anyway... > > > Also the present babeld cannot rewrite it's entire config file (so far > > as I know). I think bird can... > > > Yup, a 'bird reconfigure' will re-read the entire config file and apply > it if it parses successfully. > > > but I don't trust it. > > Your trust issues are probably best resolved between you and your daemon = ;) > > >> What we can do is to specify the format in the information model if a > >> cross-implementation format is really needed (which I'm not really > >> convinced of, either)... > > > > To quote from 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." > > > > My key points made here are "the new key is added to *all* the > > nodes"... which may or may not be up over the course of days, or weeks > > for whatever definition of "all" you have ... "Once this is done" - > > how can you tell? - "and packets are accepted if they are properly > > signed by either of the keys" hopefully you log this ... "the old key > > is removed". > > > > perhaps "deprecated, no longer actively used for signing, then removed > > after a suitable period"? > > Hmm, having a way to mark a key as "verify only" may be useful for > simpler monitoring. But really, you *could* derive the same information > from the opposite bit (track how many neighbours don't sign with the new > key yet). So then it becomes more of an efficiency issue (you could save > one signature on the wire during rotation). Not sure if it's worth > specifying another bit in the spec for this? Or if such a configuration > mode should even be in the spec at all? > > > So, if you do a key rotation and X routers are offline or inaccessible > > at that particular time... they are going to stay inaccessible > > forevermore, unless rekey'd via sneakernet, climbing on trees, and > > other forms of manual intervention. > > Presumably your key rotation policy would take into account the outage > schedules of the routers in your network? :) > > -Toke > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users --0000000000006e30b7057bac7cd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe I'm misunderstanding, but I think this issue is = not comparable to DNSSEC. The key difference here (no pun intended) is that= you can operate Babel-HMAC with multiple keys at the same time. So your ro= llover becomes a simple two step process:
0) all routers are functionin= g with OLD_KEY configured
1) go into all routers one by one and con= figure them to use both OLD_KEY and NEW_KEY
2) go into all = routers one by one and configure them to only use NEW_KEY
3) prof= it

You don't need any notion of time, or any a= dded complexity to the spec.

If some of the router= s are down during step (1), you get to decide whether to either wait for th= em to come back, or skip them and effectively disconnect them from the netw= ork based on the urgency of your key rollover. Anything beyond that becomes= a key management problem that is specific to your deployment, not to the r= outing protocol you use.

On Mon, Nov 26, 2018 at 2:22 PM Toke H=C3=B8iland-J=C3=B8rgensen &= lt;toke@toke.dk> wrote:
Dave Taht <dave.taht@gmail.com> writes:

> On Mon, Nov 26, 2018 at 1:10 PM Toke H=C3=B8iland-J=C3=B8rgensen <<= a href=3D"mailto:toke@toke.dk" target=3D"_blank">toke@toke.dk> wrote= :
>>
>> Dave Taht <dave.taht@gmail.com> writes:
>>
>> > To me this leaves the biggest problem remaining is key rotati= on. Me
>> > being me, and remembering just how hard it was to get dnssec = working
>> > on systems lacking reliable time,
>>
>> The Babel HMAC extension as currently specified does not rely on w= all
>> clock time in any way, so not really sure how a comparison to dnss= ec is
>> relevant?
>
> More below. Relative time is ok, too. 3000 seconds from now, start
> rolling over. Stop signing records with the old key as soon as
> everyone you can currently hear uses the new key, 6000 seconds from > now, retire the old key unconditionally.

Well, you would handle this by whatever mechanism you use to configure
your routers in the first place...

>> > Setting that aside for the moment, having a standardized file= format
>> > for babel keys would be a boon and boost interoperability bet= ween
>> > bird/babel and other possible implementations.
>>
>> From the point of view of each routing daemon this would just make= Babel
>> a special snowflake.
>
> ok. That leaves how to get new keys into nodes running different
> daemons. Anyone for IKEv2?
>
> My out of bound way is via scp and ssh.

I think Juliusz' insistence that we shouldn't reinvent key distribu= tion
is wise. See above; you need to configure the daemons in the first place anyway...

> Also the present babeld cannot rewrite it's entire config file (so= far
> as I know). I think bird can...


Yup, a 'bird reconfigure' will re-read the entire config file and a= pply
it if it parses successfully.

> but I don't trust it.

Your trust issues are probably best resolved between you and your daemon ;)=

>> What we can do is to specify the format in the information model i= f a
>> cross-implementation format is really needed (which I'm not re= ally
>> convinced of, either)...
>
> To quote from appendix A:
>
> "In order to perform key rotation, the new key is added to all th= e
> 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."
>
> My key points made here are "the new key is added to *all* the > nodes"... which may or may not be up over the course of days, or = weeks
> for whatever definition of "all" you have ... "Once thi= s is done" -
> how can you tell? -=C2=A0 "and packets are accepted if they are p= roperly
> signed by either of the keys" hopefully you log this ... "th= e old key
> is removed".
>
> perhaps "deprecated, no longer actively used for signing, then re= moved
> after a suitable period"?

Hmm, having a way to mark a key as "verify only" may be useful fo= r
simpler monitoring. But really, you *could* derive the same information
from the opposite bit (track how many neighbours don't sign with the ne= w
key yet). So then it becomes more of an efficiency issue (you could save one signature on the wire during rotation). Not sure if it's worth
specifying another bit in the spec for this? Or if such a configuration
mode should even be in the spec at all?

> So, if you do a key rotation and X routers are offline or inaccessible=
> at that particular time... they are going to stay inaccessible
> forevermore, unless rekey'd via sneakernet, climbing on trees, and=
> other forms of manual intervention.

Presumably your key rotation policy would take into account the outage
schedules of the routers in your network? :)

-Toke

_______________________________________________
Babel-users mailing list
Ba= bel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/= cgi-bin/mailman/listinfo/babel-users
--0000000000006e30b7057bac7cd3-- From nobody Tue Nov 27 19:30:07 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E49B130EDF for ; Tue, 27 Nov 2018 19:30:06 -0800 (PST) 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_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 Iv6xTdfJxMsH for ; Tue, 27 Nov 2018 19:30:04 -0800 (PST) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FEE130EDA for ; Tue, 27 Nov 2018 19:30:04 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id D4E1121455; Wed, 28 Nov 2018 03:30:00 +0000 (UTC) From: Dave Taht To: David Schinazi Cc: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= , babel-users@lists.alioth.debian.org, Barbara Stark , babel@ietf.org References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> Date: Tue, 27 Nov 2018 19:29:49 -0800 In-Reply-To: (David Schinazi's message of "Tue, 27 Nov 2018 13:42:54 -0800") Message-ID: <87d0qp3mmq.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 28 Nov 2018 03:30:06 -0000 David Schinazi writes: > I feel strongly against making anything but SHA-256 mandatory to > implement. It will delay publication and not improve the > interoperability story. That said, I agree that the Blake2 family is a > good fit here so it would be nice to have bird and babeld support them > - but they do not need to be in the spec. Are we weeks, months, or years away from publication? Do we have time to, like, actually code up, and test interoperability, performance, and methods, before prague? > > David > > On Mon, Nov 26, 2018 at 12:59 PM Toke H=C3=B8iland-J=C3=B8rgensen > wrote: > > "STARK, BARBARA H" writes: >=20=20=20=20=20 > > FYI. IETF policies re "downrefs" in standards track RFCs is > described in > > https://tools.ietf.org/html/rfc3967 (and updated by > https://tools.ietf.org/html/rfc8067). > > In short, it's not prohibited, but careful review is required.=20 > > Note RFC3967 Section 2 first bullet > > > > There are a number of circumstances in which an IETF document > may > > need to make a normative reference to a document at a lower > maturity > > level, but such a reference conflicts with Section 4.2.4 of > > [RFC2026]. For example: > > > > o A standards track document may need to refer to a protocol or > > algorithm developed by an external body but modified, adapted, > or > > profiled by an IETF informational RFC, for example, MD5 > [RFC1321] > > and HMAC [RFC2104]. Note that this does not override the IETF's > > duty to see that the specification is indeed sufficiently clear > to > > enable creation of interoperable implementations. >=20=20=20=20=20 > Ah, so HMAC itself is already an informational RFC? Great, let's > do > blake2, then! :D >=20=20=20=20=20 > -Toke >=20=20=20=20=20 > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users >=20=20=20=20 > > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users From nobody Wed Nov 28 02:06:41 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5654712D4ED for ; Wed, 28 Nov 2018 02:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sMiD9kB02BDy for ; Wed, 28 Nov 2018 02:06:37 -0800 (PST) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3630128C65 for ; Wed, 28 Nov 2018 02:06:36 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id AAEEF221E9; Wed, 28 Nov 2018 10:06:33 +0000 (UTC) From: Dave Taht To: babel@ietf.org, babel-users@lists.alioth.debian.org Date: Wed, 28 Nov 2018 02:06:22 -0800 Message-ID: <87in0h1ppd.fsf@taht.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] key rotation take #2 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, 28 Nov 2018 10:06:38 -0000 OK, nobody liked timestamps and the dnssec analogy, nor standardizing on an easily distributable out of band key format. I can live with that. However, what I would like to be doing is testing the key signing, and rollover methods, and measuring the overhead of HMAC-ing twice, as well as the effects (and bugs) on unicast and multicast transmissions and the rollover process itself, and interoperability between bird and babel. So here's a simpler alternate suggestion for configuring the the thing. It is not intended as an ietf standard but as a means to deploy tests of key rollovers. This is the present babel conf file format: key id key1 type sha1 value deadbeefdeadbeefdeadbeefdeadbeefdeadbeef key id key2 type sha1 value dea2f0d01a57b0071057a11da7adeadbeeffffff default enable-timestamps true unicast true hmac key1 interface enp7s0 unicast false hmac key1 interface wlps3 type wireless interface enp4s0 interface wg1 hmac key2 so we invent a new keyword "serial". a key rollover is initiated by adding a new key with the same name and a larger serial number than the old one. A key id line with no serial keyword has an implied serial number of 0. A new line gets added (via conf or configuration interface) that looks like this: key id key2 type blake2s serial 1 value dea2f0d01a57b0071057a11da7adeadbeefffff0 *the protocol* retires the old key as soon as possible. the admin removes the old key when convenient and safe to do so. Does that work for everybody? PS it would be mildly more compact to use base64 to encode the key. /me hides From nobody Wed Nov 28 03:39:18 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C94B130F7B for ; Wed, 28 Nov 2018 03:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MpD2od-lGy4 for ; Wed, 28 Nov 2018 03:39:14 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119D6128CF3 for ; Wed, 28 Nov 2018 03:39:14 -0800 (PST) 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=1543405146; bh=vRO53SS4fB+hpbfgm4cQTAVa8peOy5WAhxAA1z9znGE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ttQZnmo1B/TaBpsIqTP+eWQG5aQefBFbnXNtXAXa/gzWH5c09JOLUTHA9AYC3+A4M 6jHyxKXIZrsRCgW3sLq3r358wke09mDwsPRuzCn31pTcW6vBUiIds2XSVhKD0udljj 5vXFA4OWnpT/I+Cws7H0lH7j0w//tQLXkap65gYyG5rCv1o/RV3rrjPeuWQbOV7PZQ zaGHo7oBiprfoReEzXYXXo1cjo6JWtmMHrsY1xHrUlrPTs3YUDB89Gwm7IVQJRXrT/ WzRefeH9cRxb9HadXj3wGffWp3Jgp7L+RyW26r/5RcyPoGjuVsQyNwxZnBNqwa0kEh mMNL3idD243yA== To: David Schinazi Cc: Barbara Stark , Dave Taht , babel-users@lists.alioth.debian.org, babel@ietf.org In-Reply-To: References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> Date: Wed, 28 Nov 2018 12:39:05 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87o9a9v3c6.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 28 Nov 2018 11:39:16 -0000 David Schinazi writes: > I feel strongly against making anything but SHA-256 mandatory to > implement. > It will delay publication Not if there's already a draft we can simply refer to (like with SHA-256); I do agree that we shouldn't be trying to pull Blake through the IETF process if there isn't... > and not improve the interoperability story. Why not? If it's not MTI you risk the case where you get to pick between "good performance on weak devices" and "interoperability with RFC-only implementations". -Toke From nobody Wed Nov 28 03:41:03 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78291130F78 for ; Wed, 28 Nov 2018 03:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw4vB8W4k86M for ; Wed, 28 Nov 2018 03:40:59 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5D0128CF3 for ; Wed, 28 Nov 2018 03:40:59 -0800 (PST) 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=1543405257; bh=st2RLO4y1WJRXomLgS/yRyK7RTpHBN/HU0wY44vpUNE=; h=From:To:Cc:Subject:In-Reply-To:Date:From; b=SShFjMa3A8p1yCqNVm7swQlk8Do5ZcWta1hWx40PHMQvUnUQuqEYRtPYgflM0K7Vb DbKZClMYC2Ji9QUrZ3JC5vQFDPU7By8xLxqfI8Btb+slq3jtQQQ7rcfR93pnbiA0hU Q4xpUYMK+GYxmYcsNYuxgW9glWYra8Knwl6eYMQbQ5x3AjkrabUJ+pa7sGXWgpSAMv grLZ/D8NnQijSiMRVTkkxVycImZO/mZkQFeLarBB/UXz8/Bxy7OFGUsWMqmFyPSYEZ qwnv2+O7NyQF2qlw/DuMzcCzQW8brNjhE3ZteYvMh72pZF/nsLe4ze6znz41NzVRvY rsWx4If63aWBw== To: Dave Taht , David Schinazi Cc: babel-users@lists.alioth.debian.org, Barbara Stark , babel@ietf.org In-Reply-To: <87d0qp3mmq.fsf@taht.net> Date: Wed, 28 Nov 2018 12:40:57 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1kxv392.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 28 Nov 2018 11:41:01 -0000 Dave Taht writes: > David Schinazi writes: > >> I feel strongly against making anything but SHA-256 mandatory to >> implement. It will delay publication and not improve the >> interoperability story. That said, I agree that the Blake2 family is a >> good fit here so it would be nice to have bird and babeld support them >> - but they do not need to be in the spec. > > Are we weeks, months, or years away from publication? Do we have time > to, like, actually code up, and test interoperability, performance, > and methods, before prague? Seeing as we already have prototype implementations in both babeld and bird, I don't see why not; if someone volunteers to do the testing (*hint*) ;) -Toke From nobody Wed Nov 28 04:09:12 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47649130DCE for ; Wed, 28 Nov 2018 04:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZEtrdf1J2hu for ; Wed, 28 Nov 2018 04:09:08 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9533812D4EF for ; Wed, 28 Nov 2018 04:09:08 -0800 (PST) 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=1543406947; bh=utqmb/zJJoKkU/1GiZEwNU5FQ/ettjSXjE4Zd8+Iqg4=; h=From:To:Subject:In-Reply-To:References:Date:From; b=gbWMax1cVerM7mcXqRyLoKW9xS0ffOazJPMmwj+oooyHzyTLBVDwoLOFtX99Rkzi/ draDGt/RB1vQlV5VRLodT5DzoWWNYmXv2e3NeQJyMfKy0QmsjRcx7SCrVRbMYgY2gs AW+/N2OXlEJ9BEzBhDT/X1eTjE1mn2vkWTifyo6lmniWPpQNvPmg436/+rMfU6XsXc Nn4lCKWESqySt+GnNCuO+gKWN71XqcgoZjD0kRlgi3XSS6J84DR5Or9FINbddCDjgY rEcfCyy66mh8wjh4lqhrwjE6QwzdMMUSttiFTjM82uDIdErduhat9YcGgl8fc2QUzO 5BSRnQXVRUCPw== To: Dave Taht , babel@ietf.org, babel-users@lists.alioth.debian.org In-Reply-To: <87in0h1ppd.fsf@taht.net> References: <87in0h1ppd.fsf@taht.net> Date: Wed, 28 Nov 2018 13:09:05 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87efb5v1y6.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] key rotation take #2 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, 28 Nov 2018 12:09:10 -0000 Dave Taht writes: > so we invent a new keyword "serial". So what you're trying to express here is the notion of a "receive-only" key that is not used for signing outgoing packets, right? If so, I think it would be better to express that explicitly as a property of the key config that can be changed on a per-key basis. For one thing, 'serial' is misleading as it sounds like something that affects the wire format, and for another with your proposal it becomes difficult to re-instate a previously retired key (say, if you want to restore connectivity to an old router that dropped off while you were changing keys). -Toke From nobody Wed Nov 28 04:09:47 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0687012D4EF for ; Wed, 28 Nov 2018 04:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrzSLL92HNyY for ; Wed, 28 Nov 2018 04:09:41 -0800 (PST) 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 1D697128CE4 for ; Wed, 28 Nov 2018 04:09:40 -0800 (PST) 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 wASC9WG2005084; Wed, 28 Nov 2018 13:09:32 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9AEFB260C9; Wed, 28 Nov 2018 13:09:38 +0100 (CET) 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 QKvLNQrs7pmM; Wed, 28 Nov 2018 13:09:36 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AEC6D260C7; Wed, 28 Nov 2018 13:09:35 +0100 (CET) Date: Wed, 28 Nov 2018 13:09:35 +0100 Message-ID: <875zwhxv28.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , babel-users@lists.alioth.debian.org, babel@ietf.org In-Reply-To: <87o9a9v3c6.fsf@toke.dk> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 28 Nov 2018 13:09:32 +0100 (CET) X-Miltered: at korolev with ID 5BFE857C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BFE857C.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 : 5BFE857C.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] [Babel-users] rather than ripemd160... 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, 28 Nov 2018 12:09:45 -0000 > Why not? If it's not MTI you risk the case where you get to pick between > "good performance on weak devices" and "interoperability with RFC-only > implementations". Is there any evidence that there are devices that can reasonably run Babel and that are too weak to use SHA256 for protecting control traffic? I don't have an ARM device handy right now, but a 450MHz MIPS 24Kc is able to SHA256 on the order of 16MB/s. That's 10000 full-size frames per second, or on the order of 600000 Babel updates per second. My suggestion is to implement whatever the list recommends (Blake2B or 2S) in both BIRD and babeld, but to keep the status quo (SHA256 is MTI) in the spec. -- Juliusz From nobody Wed Nov 28 08:31:23 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EF512872C for ; Wed, 28 Nov 2018 08:31:21 -0800 (PST) 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_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 mQMrkCb4WE_y for ; Wed, 28 Nov 2018 08:31:19 -0800 (PST) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD061277BB for ; Wed, 28 Nov 2018 08:31:19 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 000AC221E9; Wed, 28 Nov 2018 16:31:16 +0000 (UTC) From: Dave Taht To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: babel@ietf.org, babel-users@lists.alioth.debian.org References: <87in0h1ppd.fsf@taht.net> <87efb5v1y6.fsf@toke.dk> Date: Wed, 28 Nov 2018 08:31:05 -0800 In-Reply-To: <87efb5v1y6.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\= \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of "Wed, 28 Nov 2018 13:09:05 +0100") Message-ID: <877egx17w6.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] [Babel-users] key rotation take #2 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, 28 Nov 2018 16:31:21 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > Dave Taht writes: > >> so we invent a new keyword "serial". > > So what you're trying to express here is the notion of a "receive-only" > key that is not used for signing outgoing packets, right? No... the old key is retired from active use in the protocol after concensus is achieved on the new key by the protocol, and not used again unless a router comes up with an unreadable hmac. In that case we go back to at least trying to verify (periodically?) that it's not using the old key (if we still have it around) and if it's using the old key, we go back to signing stuff with that key. Does that concept need to be in the protocol spec? >If so, I think Mmmm... I would say that I'm trying to institute key rollover on an unreliable not-always fully connected network that may or may not be under attack. As one example, I have a rogue AP on the network right now. I can't get into it, nor can I physically find it, but it's exchanging routes. I can block the routerid on the devices that can hear it via changing the conf file on the devices that can hear it, but it's "loud" so as fast as I get rid of the closer machines that can hear it, others pick it up. Another worse case scenario is that it's announcing routes to 8.8.8.8 with a metric of zero, and also ping flooding the network probing for every address in the 10.0.0.0/8 range, and every time I try to block the routerid, it changes. In this case you'd want to add a new key, and retire the old one as fast as possible, but that's only "as possible". ... I don't know if you've been in a world where every keystroke takes 10 seconds to transmit, but I have some horror stories that oft require beer to tell. One attack (in 2004) literally melted down the switch... the QA team deployed 60? windows virtual machines - fresh installs - virgins - no anti-virus or upgrades installed - and unbnownst to my team a worm was already loose on one machine on that network. Inside of 10 minutes it had grabbed all 60 vms, and it was on a 10 network, and thus every machine started probing the entire /8... and doing a DOS on every machine it could find - which included those vms - the carnage proceeded until the switch overheated and failed overnight. 3AM, we blindly replaced the switch only to see all the lights go solid again. It's not obvious you're under attack at that point (things like broadcast storms we explored first), and it wasn't until the QA guy responsible wandered in at noon wondering why it was taking 10 seconds for each keystroke to get through to his shiny new QA network that light dawned on us... "You did *what*???" > it would be better to express that explicitly as a property of the key > config that can be changed on a per-key basis. For one thing, 'serial' > is misleading as it sounds like something that affects the wire > format, OK. how about "new" and "old" as keywords? That implies two states and two states only. I liked 0 and X as numbers, so long as the ascending property is maintained. As for why not 0 and 1, see below. Totally open to bikeshedding the name. :) babeltowerno?=20 > and for another with your proposal it becomes difficult to re-instate a > previously retired key (say, if you want to restore connectivity to an > old router that dropped off while you were changing keys). No it doesn't. you just would reinstate the prior key with the smaller serial number. Or if you've gone back to 0 for it you increment the current key to 1 and then put in the 0th one. another use case: I have 6 campus routers in the lab that are not powered on right now, pending a reflash with the latest stuff. Worse, they used to be connected to a far-off portion of the network and when I bring them up, they start announcing routes to that bit (and the longer prefixes overall mean they end up being my default route to the rest of the campus network, over a really crappy link going from the basement to the roof). I do a key upgrade throughout the net and they can no longer do any harm, and can deal with each via a dedicated reconfiguration router that filters them out before they hit the rest of the net. Yea! Over time I'll end up with a file full of retired keys. (there are still 20+ machines not powered up in the lab and the rest are being donated to charity) > -Toke From nobody Wed Nov 28 08:51:33 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A59130E27 for ; Wed, 28 Nov 2018 08:51:32 -0800 (PST) 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_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 kjIOpWahXa1R for ; Wed, 28 Nov 2018 08:51:30 -0800 (PST) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADACB130E72 for ; Wed, 28 Nov 2018 08:51:29 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id B8781221E9; Wed, 28 Nov 2018 16:51:27 +0000 (UTC) From: Dave Taht To: Juliusz Chroboczek Cc: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= , babel-users@lists.alioth.debian.org, babel@ietf.org References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> Date: Wed, 28 Nov 2018 08:51:16 -0800 In-Reply-To: <875zwhxv28.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Wed, 28 Nov 2018 13:09:35 +0100") Message-ID: <8736rl16yj.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 28 Nov 2018 16:51:32 -0000 Juliusz Chroboczek writes: >> Why not? If it's not MTI you risk the case where you get to pick between >> "good performance on weak devices" and "interoperability with RFC-only >> implementations". > > Is there any evidence that there are devices that can reasonably run Babel > and that are too weak to use SHA256 for protecting control traffic? > > I don't have an ARM device handy right now, but a 450MHz MIPS 24Kc is able > to SHA256 on the order of 16MB/s. That's 10000 full-size frames per second, > or on the order of 600000 Babel updates per second. Sigh. Benchmarks. In particular I loathe benchmarks that do just one small thing repeatedly, fully in i and dcache and claim "that's how fast it is". No, you go and measure the impact on the total system, under a real workload, changing whether you have hmac on or off, to draw a conclusion. In the crypto case especially, people are really fond of large block sizes, and not fond of showing lots of very small ones. startup overhead can be significant. It takes a really long time to sha1 one byte. Hardware crypto offloads for packets, from userspace, as another example, are generally a lose, due to the kernel/userspace transition required. Lastly... Routers *are* doing other things besides exchanging routes, like moving packets around and dns, dhcp, and so on. Complex systems have emergent properties that don't show up without "all up testing", which often results in "RUD" - rapid unscheduled dissassembly. I already showed with the rtod experiments that a sufficient number of routes can disable the dns and dhcp daemons, on a low end router. Your typical low end router forwards packets until it runs out of cpu, which is usually well below line rate. Processing packets locally eats even more cpu. We also tried in the last battlemesh we went at, to coax those trying to measure convergence times to also measure them under heavy load. I don't know if toke's preso on the second+ long delays that network experienced fully registered (but we went off and fixed wifi regardless). I would rather like to make battlemesh this year... with working hmac, unicast, kick-arse wifi, and other whizbang new features and bugfixes. ... I'm trying to redteam these ideas. If a given attacker hits me with 10,000 babel packets a second, unauthed, do I die? If I try valiantly to verify these packets and fail, do I die sooner? If I figure out I'm under attack from this particular box, can I blackhole all/most its packets and move on, and not die at all? (RRL in bind is an example) And honestly, all I'm pushing for at the moment is a way to do key rotation, and it would be good to be able to have two algorithms to evaluate. > > My suggestion is to implement whatever the list recommends (Blake2B or 2S) > in both BIRD and babeld, but to keep the status quo (SHA256 is MTI) in the spec. I can live with that, but would prefer to have running code to deploy at some scale, and measure. > -- Juliusz > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users From nobody Wed Nov 28 09:41:40 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FBD130E8B for ; Wed, 28 Nov 2018 09:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2prMrN8Ulsc for ; Wed, 28 Nov 2018 09:41:35 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 C3C221277BB for ; Wed, 28 Nov 2018 09:41:35 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id x21-v6so17714499pln.9 for ; Wed, 28 Nov 2018 09:41:35 -0800 (PST) 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=7CbUMobb5j6m0+DEgHMCV2yEgVk09uSL+Ae/3B/uIfQ=; b=IQkVQEvdhLcwf3RuPzA8Lro8X21ti6Owln8ZycQy7w3fzZ+jblIdfKEFnAFwQrbbrK 4Z7I4Jg5RPLRmuRJGi+uXoebKB7/ILH9VpR4AdjTeCxMsjX5QIYWEoBPVdD/IOk4naiS Zio3lPS7ZI6aVvlvVAJlZeGUqZ/Si+t0F89EnN+hmUWuvxqWzZvsm23DXHqEMN4TBVy8 eRjjjsKwEtdGps9FWqaaefZElllJ3nKX8Ow4HNk1gwFPVn2U9W7kwsHtJ4Fe8mmkrrQH gvK9f4fWc9liuabg2c0rhIr06Zk4RoJqDY9mTjr67RNRCoZpHm3xndHAelncdkvf5kSB xuRg== 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=7CbUMobb5j6m0+DEgHMCV2yEgVk09uSL+Ae/3B/uIfQ=; b=kexopz3bOocdKEC2tlvuF7J3vg+sGRiWv+jIPFsx2ug8oggnDHp3vw6qw7JMRS+g1Z EyG0YHHbLWwMXHKZDMFKLR/ezR02uAzw+Ca1EJOxILd/LQhC3+l6dYjiABboJDBVhZSp Vs4JEVUQwod3SW3Rg4DltagWH0K8pL9wy4zzn1Zt0eDN2BVSBSbZBFWNbe7oIaKEiJCF 0Xy5qrts7ekX8rLntkusgDc6VqsLQFKOnRqUqqdYUX5RuX+yb5+d8DGNPSWSOkcWnYDj 4lCjw/8QYP1M1OcbzotaLYlQHyt4SkgW0hx8sAGmRMtZfvcPgr7SyrnWjlDaxQ7B7i25 m8dg== X-Gm-Message-State: AA+aEWY7F4QCvwIzHqS6cX6HyTdCd7bHC6CflF2Ew9Uj0IYNO9996KrT r3O8GKI9x8V+f7fHewmRksPdGBnhgUkTQeyFT58= X-Google-Smtp-Source: AFSGD/VQd+gBdmaz0omH0OrT+v3xEL6+nOt84C4c789DekHE6mQWj6vBexAvyk262K2CI4GfJIsYQDJhE5N0ZJ+kov8= X-Received: by 2002:a17:902:50e:: with SMTP id 14mr29557961plf.141.1543426895387; Wed, 28 Nov 2018 09:41:35 -0800 (PST) MIME-Version: 1.0 References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> In-Reply-To: <87o9a9v3c6.fsf@toke.dk> From: David Schinazi Date: Wed, 28 Nov 2018 09:41:23 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Barbara Stark , Dave Taht , babel-users@lists.alioth.debian.org, babel@ietf.org Content-Type: multipart/alternative; boundary="000000000000d62004057bbd13d5" Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 28 Nov 2018 17:41:39 -0000 --000000000000d62004057bbd13d5 Content-Type: text/plain; charset="UTF-8" > > > Why not? If it's not MTI you risk the case where you get to pick between > "good performance on weak devices" and "interoperability with RFC-only > implementations". > Where are these "RFC-only implementations" of Babel? Remember the IETF does not have a protocol police, MTI is purely guidance. Implementors build what they (or their customers) need for their use-case. Implementors will add Blake if they need it, not based on whether it's MTI or not. Lastly, remember that this is a security solution, so you do NOT want to interoperate with a future theoretical implementation, because that will not have the keys. Adding any new node in the network will require a provisioning step, and that step ensures the new node supports the required features. --000000000000d62004057bbd13d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=
Why not? If it's not MTI you risk the case where you get to pick betwee= n
"good performance on weak devices" and "interoperability wit= h RFC-only
implementations".

Where are these = "RFC-only implementations" of Babel?
Remember the IETF = does not have a protocol police, MTI is purely guidance.
Implemen= tors build what they (or their customers) need for their use-case.
Implementors will add Blake if they need it, not based on whether it'= s MTI or not.
Lastly, remember that this is a security solution, = so you do NOT want to
interoperate with a future theoretical impl= ementation, because that will
not have the keys. Adding any new n= ode in the network will require a
provisioning step, and that ste= p ensures the new node supports the
required features.
= =C2=A0
--000000000000d62004057bbd13d5-- From nobody Wed Nov 28 12:17:24 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412A5130FB5 for ; Wed, 28 Nov 2018 12:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0u-GwvVya5S for ; Wed, 28 Nov 2018 12:17:21 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785DF127B92 for ; Wed, 28 Nov 2018 12:17:21 -0800 (PST) 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=1543436235; bh=etUs+A5e3dERqCyP62l5w4jJ74IYrx4/XUi2gyQd75k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=uTv6nYP3PKxXghVOqFdXpk1n1uWxJ+XqX/tmhm6DwNXTaO3cwp87xGjeGoT+i9J5j 8TGK+B4o0CetfH6755iAnRHmT3Mc16Jsz4u/83RJrvprJ9Lhe7loIpDoUooGZFgEZf 083vig1qOb7dbXmAEUNXK6cXLLN28HMWV5E19uMDNf45OVXYF56Dz5FNsBHF7Ql8L5 QbPvDVwYGx56oE5vQj8OdodRs/8h7QHhiyIo/OvI5wRivWJebv8vVbZlbOq50oRAIC Z5gf/T8WALV5cyNSjBEiE0KMieq5Q3ajZvNNygf/mQ7VDpWPWT0q/1f+EcmBevW3D7 pQaALDEjMZJ/Q== To: David Schinazi Cc: Barbara Stark , Dave Taht , babel-users@lists.alioth.debian.org, babel@ietf.org In-Reply-To: References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> Date: Wed, 28 Nov 2018 21:17:15 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wooxt0s4.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 28 Nov 2018 20:17:23 -0000 David Schinazi writes: >> >> >> Why not? If it's not MTI you risk the case where you get to pick between >> "good performance on weak devices" and "interoperability with RFC-only >> implementations". >> > > Where are these "RFC-only implementations" of Babel? Anyone who does a from-scratch implementation from the RFC, without being part of the working group process, or looking at the existing implementations. > Remember the IETF does not have a protocol police, MTI is purely > guidance. Implementors build what they (or their customers) need for > their use-case. Implementors will add Blake if they need it, not based > on whether it's MTI or not. If it's MTI, they can't claim compliance with the RFC until it's in there. So the "we need this box checked" type of product development will benefit from this; and while sure, theoretically MTI is a hint, it's a pretty strong one... > Lastly, remember that this is a security solution, so you do NOT want > to interoperate with a future theoretical implementation, because that > will not have the keys. Adding any new node in the network will > require a provisioning step, and that step ensures the new node > supports the required features. You can usually control the config, but not necessarily the features implemented by the device... -Toke From nobody Wed Nov 28 12:23:52 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72926130E23 for ; Wed, 28 Nov 2018 12:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6NXEQl57Dyf for ; Wed, 28 Nov 2018 12:23:49 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F821130FDB for ; Wed, 28 Nov 2018 12:23:49 -0800 (PST) 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=1543436627; bh=cOi2axPton/Bs0pi238bKeYMljULjk6+Ux5i6hhKiiE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=sNODZxf9D4+XZ2I3okNseWoa33//0Y8wjjpBhFJ03rkIZedt/fmiMj/HlD0EYFnyI kdl4OCqnhj5gALdtvh7uDMUr8hpDVy2cofk1LXxg4NtvFq/jCf8+mFSiQxT0b1jPmI OW3ObdsY4rPTSE6jhaR1s+IUbFCu+7vSywRGsLrFFeAj4P06klcPzqk4QdmrR36p+D kHHYphxbI8i3vnBsZjJRQohEKYA1XaWOivdAFMisacuGA4PrRvX9Lki0r6gJiFtaV4 wp6dO9eyQrKFxXgtyNqefL6jZ9BKNncYMVanjQU2rrNf5WcesJVtNxq8vH8LYJbfrj xkLjZmokJGCyQ== To: Dave Taht Cc: babel@ietf.org, babel-users@lists.alioth.debian.org In-Reply-To: <877egx17w6.fsf@taht.net> References: <87in0h1ppd.fsf@taht.net> <87efb5v1y6.fsf@toke.dk> <877egx17w6.fsf@taht.net> Date: Wed, 28 Nov 2018 21:23:46 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87tvk1t0h9.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] [Babel-users] key rotation take #2 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, 28 Nov 2018 20:23:51 -0000 Dave Taht writes: > Toke H=C3=B8iland-J=C3=B8rgensen writes: > >> Dave Taht writes: >> >>> so we invent a new keyword "serial". >> >> So what you're trying to express here is the notion of a "receive-only" >> key that is not used for signing outgoing packets, right? > > > No... the old key is retired from active use in the protocol after > concensus is achieved on the new key by the protocol, and not used > again unless a router comes up with an unreadable hmac. In that case > we go back to at least trying to verify (periodically?) that it's not > using the old key (if we still have it around) and if it's using the > old key, we go back to signing stuff with that key. > > Does that concept need to be in the protocol spec? This reads to me like a specific operational procedure for deployment; don't think that should go into the spec, no. >> it would be better to express that explicitly as a property of the key >> config that can be changed on a per-key basis. For one thing, 'serial' >> is misleading as it sounds like something that affects the wire >> format, > > OK. how about "new" and "old" as keywords? That implies two states and > two states only. I liked 0 and X as numbers, so long as the ascending > property is maintained. As for why not 0 and 1, see below. > > Totally open to bikeshedding the name. :) babeltowerno? Don't care what they are called. My point is just that it's a property of a particular key. Bird already has this, BTW: each key can be set to "generate" signatures and "accept" signatures, where the former puts them on the wire, and the latter will accept packets signed with that key. You can set time ranges for each or both. See https://bird.network.cz/?get_doc&v=3D20&f=3Dbird-3.html (search for "password option"). The Babel HMAC implementation inherits this. -Toke From nobody Wed Nov 28 13:04:11 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E27130EE4 for ; Wed, 28 Nov 2018 13:04:10 -0800 (PST) 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_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 wPh5JnQqhtL4 for ; Wed, 28 Nov 2018 13:04:08 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 DAEED130E27 for ; Wed, 28 Nov 2018 13:04:07 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id o125so17750290qkf.3 for ; Wed, 28 Nov 2018 13:04:07 -0800 (PST) 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=HEQd7XF1e2l6CzPVLP4yDC5KSnAFWsdEPUufy3BKDpo=; b=m8eYEyzxM7A6zh77ltRnM/v25+DUQtEXqFxEs6V2Ziag6BSij4zA2ODkKEELm3ycye sz9D0SqBFZPNmlJrl4DxYP1IGe4DNk6R8PpHDx+i/guv6H8SepSqquVPrLS++odLRM7W tjn+jgl50o3Zh7FPjr+k/KjkkKECdjE6fd/Q8dqGlHZ8E35d3hbAjUfUBzI0rbAt2+ta HT0BE3OhPdWi/YVgtr5zQhJIpC/75SjG4nfyZuKKA0f+ogfX3HuaVceQqaLho8WHg2kL BqS3y7DRHBwW6JvxZfDlPNw+mxvp96u0/1kn4N2OPAqgFHRPMEUi54Raw0V02+HU1OWP Kvjg== 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=HEQd7XF1e2l6CzPVLP4yDC5KSnAFWsdEPUufy3BKDpo=; b=meXXFa6XsRKJ040UQKt1gZuvJwq7PLUwFB7qfRl2fgHtE+cqQ3B0l1Ays1xSH2JHKT 6Fv3WMzxSdHH4hJK2HW9GVIuiSdxwm8539D63VZBFdiI1KvnAB2scPXUctDVp8gMTMrF H3zZkcP1hPObxMvFTu46VpWdIgNVIkZqK6eGmSeYUfMpTN872u0Wj+ycR2MKYpGlLmKr XDCxGpD6oh3O5nOlBzV3sh/pkrnpWNDEO9Gg9tEGVOptI+jhRuQCyH3STqZhSJxqWePv vaJfo+NVOeXUIEMewY/rxc+3isfJmydGMfKlhdEGKlOtvGr0dd4Y6dv/ZqFndxAv0sdD O5RA== X-Gm-Message-State: AA+aEWbH7Q/6T/vGo37+lSe19Q2f2MMHvQuFEe5TtPb3MePW7czhrJeU oZe/yB7OuvWGxYPRCuJ00pDthX+qsZgITUbzmG6tsg== X-Google-Smtp-Source: AFSGD/XJb/x1Zg07PH2yCWQj/W/iQkNDBOM5yksZ6avyUb7aNegGxFbba5pLjwCGejNwLU3Zn0RQ2mUsjKsrYwaJWV0= X-Received: by 2002:a37:18d5:: with SMTP id 82mr34509962qky.65.1543439046870; Wed, 28 Nov 2018 13:04:06 -0800 (PST) MIME-Version: 1.0 References: <87in0h1ppd.fsf@taht.net> <87efb5v1y6.fsf@toke.dk> <877egx17w6.fsf@taht.net> <87tvk1t0h9.fsf@toke.dk> In-Reply-To: <87tvk1t0h9.fsf@toke.dk> From: Dave Taht Date: Wed, 28 Nov 2018 13:03:55 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: =?UTF-8?Q?Dave_T=C3=A4ht?= , babel-users , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] [Babel-users] key rotation take #2 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, 28 Nov 2018 21:04:11 -0000 On Wed, Nov 28, 2018 at 12:23 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Dave Taht writes: > > > Toke H=C3=B8iland-J=C3=B8rgensen writes: > > > >> Dave Taht writes: > >> > >>> so we invent a new keyword "serial". > >> > >> So what you're trying to express here is the notion of a "receive-only= " > >> key that is not used for signing outgoing packets, right? > > > > > > No... the old key is retired from active use in the protocol after > > concensus is achieved on the new key by the protocol, and not used > > again unless a router comes up with an unreadable hmac. In that case > > we go back to at least trying to verify (periodically?) that it's not > > using the old key (if we still have it around) and if it's using the > > old key, we go back to signing stuff with that key. > > > > Does that concept need to be in the protocol spec? > > This reads to me like a specific operational procedure for deployment; > don't think that should go into the spec, no. > > >> it would be better to express that explicitly as a property of the key > >> config that can be changed on a per-key basis. For one thing, 'serial' > >> is misleading as it sounds like something that affects the wire > >> format, > > > > OK. how about "new" and "old" as keywords? That implies two states and > > two states only. I liked 0 and X as numbers, so long as the ascending > > property is maintained. As for why not 0 and 1, see below. > > > > Totally open to bikeshedding the name. :) babeltowerno? > > Don't care what they are called. My point is just that it's a property > of a particular key. > > Bird already has this, BTW: each key can be set to "generate" signatures > and "accept" signatures, where the former puts them on the wire, and the > latter will accept packets signed with that key. You can set time ranges > for each or both. See > https://bird.network.cz/?get_doc&v=3D20&f=3Dbird-3.html (search for > "password option"). The Babel HMAC implementation inherits this. That is essentially my first proposal... in bird syntax. :) Aside from needing good time, there are really good reasons to stage key rotations that way.... while the odds are much better that a boot/bootstrapping bird router has a working rtc, your typical home router doesn't. > > -Toke > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Wed Nov 28 13:19:54 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E292A1274D0 for ; Wed, 28 Nov 2018 13:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqiYbv1OQzli for ; Wed, 28 Nov 2018 13:19:44 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774A9126DBF for ; Wed, 28 Nov 2018 13:19:44 -0800 (PST) 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=1543439982; bh=P7lvcG1eb4UQsTLOMnJO64iQ9qvhnI3zsN8XA9QjDIE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Lyt2+QIZADQTxBMptbyfW5WvOgoc4+CxJuSdJH16a/XicSyUbdwwdKYdGrnymqVUp KaItKDQVBCVuAsAi9Y8LJzmj4OSyaGqPneaXP5QIC/FnbHtvTa0zbpIUwWmc2Xsj9D rCU9umLur8E8eKur5o2ejZJnCgieEvaoowj+PQuxcrE1euEXOxkT9R+B0LmGWPglkC owBDGzMQtbKnJvDbgMRU5ny1HFZyI8plXfImwg1Za15IJn6EtEvffT8qE5dTodrtlA mupto2xOEkZtGDBqwqR7scatjCVb9wQwKtlw88QnGWpwTpemlyubOWrAn2alTHWWqZ 7kVuhguohaXBg== To: Dave Taht Cc: Dave =?utf-8?Q?T=C3=A4ht?= , babel-users , Babel at IETF In-Reply-To: References: <87in0h1ppd.fsf@taht.net> <87efb5v1y6.fsf@toke.dk> <877egx17w6.fsf@taht.net> <87tvk1t0h9.fsf@toke.dk> Date: Wed, 28 Nov 2018 22:19:41 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lg5cucgi.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] [Babel-users] key rotation take #2 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, 28 Nov 2018 21:19:47 -0000 Dave Taht writes: > On Wed, Nov 28, 2018 at 12:23 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> Dave Taht writes: >> >> > Toke H=C3=B8iland-J=C3=B8rgensen writes: >> > >> >> Dave Taht writes: >> >> >> >>> so we invent a new keyword "serial". >> >> >> >> So what you're trying to express here is the notion of a "receive-onl= y" >> >> key that is not used for signing outgoing packets, right? >> > >> > >> > No... the old key is retired from active use in the protocol after >> > concensus is achieved on the new key by the protocol, and not used >> > again unless a router comes up with an unreadable hmac. In that case >> > we go back to at least trying to verify (periodically?) that it's not >> > using the old key (if we still have it around) and if it's using the >> > old key, we go back to signing stuff with that key. >> > >> > Does that concept need to be in the protocol spec? >> >> This reads to me like a specific operational procedure for deployment; >> don't think that should go into the spec, no. >> >> >> it would be better to express that explicitly as a property of the key >> >> config that can be changed on a per-key basis. For one thing, 'serial' >> >> is misleading as it sounds like something that affects the wire >> >> format, >> > >> > OK. how about "new" and "old" as keywords? That implies two states and >> > two states only. I liked 0 and X as numbers, so long as the ascending >> > property is maintained. As for why not 0 and 1, see below. >> > >> > Totally open to bikeshedding the name. :) babeltowerno? >> >> Don't care what they are called. My point is just that it's a property >> of a particular key. >> >> Bird already has this, BTW: each key can be set to "generate" signatures >> and "accept" signatures, where the former puts them on the wire, and the >> latter will accept packets signed with that key. You can set time ranges >> for each or both. See >> https://bird.network.cz/?get_doc&v=3D20&f=3Dbird-3.html (search for >> "password option"). The Babel HMAC implementation inherits this. > > That is essentially my first proposal... in bird syntax. :) Aside from > needing good time, there are really good reasons to stage key > rotations that way.... > > while the odds are much better that a boot/bootstrapping bird router > has a working rtc, your typical home router doesn't. No, but you can use the mechanism without the timeouts to mark keys as active/passive using whatever provisioning system you are using to distribute the keys (just use "{generate,accept} from 1970-01-01"). -Toke From nobody Wed Nov 28 13:56:40 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BBD131063 for ; Wed, 28 Nov 2018 13:56:35 -0800 (PST) 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_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 69GBVR9HERi7 for ; Wed, 28 Nov 2018 13:56:33 -0800 (PST) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9731310AD for ; Wed, 28 Nov 2018 13:56:32 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 8257121B39; Wed, 28 Nov 2018 21:56:29 +0000 (UTC) From: Dave Taht To: Juliusz Chroboczek Cc: babel-users@lists.alioth.debian.org, babel@ietf.org References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> Date: Wed, 28 Nov 2018 13:56:17 -0800 In-Reply-To: <8736rl16yj.fsf@taht.net> (Dave Taht's message of "Wed, 28 Nov 2018 08:51:16 -0800") Message-ID: <87o9a8zx1a.fsf_-_@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] DTLS and hmac co-existence 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, 28 Nov 2018 21:56:39 -0000 Have I been enough of a PITA this month? Section 4 of rfc6126bis-07 states: Both the source and destination UDP port are set to a well-known port number. A Babel packet MUST be silently ignored unless its source address is either a link-local IPv6 address or an IPv4 address belonging to the local network, and its source port is the well-known Babel port. Aside from the fact that all versions of babel prior to now enforced this requirement that the source and destination port numbers be the same, which is a major consideration, that idea leaked into the hmac implementation which does a: DO_HTONS(&port, (unsigned short)protocol_port); if ((err = blake2s_init_key(&S, key->len, key->value, BLAKE2S_DIGEST_LENGTH)) < 0) goto fail; /* Hash the pseudo header. */ if ((err = blake2s_update(&S, src, 16)) < 0) goto fail; if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail; ^^^^^ if ((err = blake2s_update(&S, dst, 16)) < 0) goto fail; if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail; ^^^^ the DTLS branch, on the other hand, mandates that ephemeral ports be used for DTLS communications. Section 2.1 of https://tools.ietf.org/html/draft-ietf-babel-dtls-02 The node acting as DTLS client initiates its DTLS connection from an ephemeral UDP port. Nodes SHOULD ensure that new client DTLS connections use different ephemeral ports from recently used connections to allow servers to differentiate between the new and old DTLS connections. The rub, here, ultimately, is that I could see HMAC being used to protect multicast and DTLS used to protect unicast, in which case, allowing for ephemeral src ports generally in the bis version would be helpful. I do not see how requiring a fixed src port helps anything? (besides backward compatability) Selfishly, I have to admit, that by using an ephemeral udp port for route transfers and a different, either ephemeral or 6696 for hello/ihu - fq_codel automagically distinguishes between these two very different types of traffic and in congested network conditions will drop routes far more often than hellos. A backwards compatible mechanism would be to try hellos/ihus from an ephemeral port and note when you don't get one back, upon starting an association. A key indicator to other routers no longer respecting the fixed src port rule would be recieving such. ... As a side note, I had suggested using UDP-lite for development purposes or dtls communications. It's easier to use a different protocol than it is to get a new port number out of iana... I was queried as to why udp-lite, and my answer that I never got around to saying was that once you have an HMAC, you don't need a CRC, and also, to my knowledge, udp-lite is very widely deployed, just not used. It is the same in all other respects to udp. On a single hop over ipv6, udp-lite "just works" on the versions of linux and bsd I've tried over the past 5 years. It's impossible to compile out in linux (although netfilter support for it can be), for example. From nobody Wed Nov 28 14:50:10 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAEE130DC0 for ; Wed, 28 Nov 2018 14:50:08 -0800 (PST) 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_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 xRbiWkQwYjJb for ; Wed, 28 Nov 2018 14:50:04 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 A0B4D130E27 for ; Wed, 28 Nov 2018 14:50:04 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id g9so5630331plo.3 for ; Wed, 28 Nov 2018 14:50:04 -0800 (PST) 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=9jZv700NU65/Uq9KRRm4nPlTJvoN9O9SHVTPZpobWa0=; b=j0tyNed207NOFUXTKsWcIczXYT/GWjSOUGR64DZQnAEcS8If2oqvyFdFvMVzORJLn7 Crn88nYpUGhoxLXnVUaashLBCB8fHfrGgjBQf3KVN8NH4gvOvHALzrfnqiOaj9plARkE M0tGVOpGetSNNO9m4/gywsTvK/t3e/ahHb4Obhwpgx5WhqElEe9wKvDsT6GFp5IikEyO v9nvZqQWsRcW+S45p7DDc47Xo6M1xFUi5Cy18EdgsKZffrBraXUVnzSLGYexKrqnsgjZ nnrkC6k1FfOBEKvZvAYrY+fzU66+gDluxcTHih4LcCrG3Qb6E1OrWsZNfOQUoGdjJ4k1 ue3w== 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=9jZv700NU65/Uq9KRRm4nPlTJvoN9O9SHVTPZpobWa0=; b=ny16EAKs4P3bbJxuCueWrdLJ5f29kDid8TKSB42FpS1cf6GUU092ZRE8ohviUgJPo/ ujhhZoZHxVRtZAzVECuwTKcQ3L0WXmEL3iUa4CIaXjYZKgNqFAKxFRhKACSPVQXGaNGA 8XBgputYsIgm/1DH0TlN9xREtnu/vwa0+9O5SAdmMtJGmDGbmuaqUftJ/xTGKVOKoLgH C9E2l6+PJ8xJXT9l/c8HlxKy2Ra5IIsp4/G+g49vF4UXk3+JlZ+1E/R3ATVLQg1fJWs4 lOH67w4wtj80Xt6uGm5jQSMIViLtW/BMkS//V8Jjt89+bvGwdT7NPMSkFfd2joRnD77e bDTQ== X-Gm-Message-State: AA+aEWbUr0F2qv4wczpPTxCcb4PMn5rUWVNzSFOcepf9reNRWfzgPNcn nNQlt7SuKXzDLTDK+zbnzgUhyTMCpisAVe1Nu7s= X-Google-Smtp-Source: AFSGD/WgJvHe5plde2k4Ld/8YmT/30Nh++fKo7AH8dWdXgF6pVFPlx9liVuP1ZpkqmaG6U8tT2zD+9vvZDOy5AUHtpg= X-Received: by 2002:a17:902:aa0a:: with SMTP id be10mr38244557plb.266.1543445403967; Wed, 28 Nov 2018 14:50:03 -0800 (PST) MIME-Version: 1.0 References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> <87o9a8zx1a.fsf_-_@taht.net> In-Reply-To: <87o9a8zx1a.fsf_-_@taht.net> From: David Schinazi Date: Wed, 28 Nov 2018 14:49:52 -0800 Message-ID: To: dave@taht.net Cc: Juliusz Chroboczek , babel-users@lists.alioth.debian.org, babel@ietf.org Content-Type: multipart/alternative; boundary="00000000000008a5b2057bc1634b" Archived-At: Subject: Re: [babel] [Babel-users] DTLS and hmac co-existence 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, 28 Nov 2018 22:50:09 -0000 --00000000000008a5b2057bc1634b Content-Type: text/plain; charset="UTF-8" Hi Dave, The Babel over DTLS spec states that - unicast traffic is sent over DTLS, where DTLS client uses an ephemeral port, and DTLS server uses a well-known port different from 6696 - multicast traffic still uses 6696 for source and destination I don't see any issues with protecting Hellos with HMAC and everything else with DTLS. David On Wed, Nov 28, 2018 at 1:56 PM Dave Taht wrote: > > Have I been enough of a PITA this month? > > Section 4 of rfc6126bis-07 states: > > Both the source and destination UDP port are set to a well-known port > number. A Babel packet MUST be silently ignored unless its source > address is either a link-local IPv6 address or an IPv4 address > belonging to the local network, and its source port is the well-known > Babel port. > > Aside from the fact that all versions of babel prior to now enforced > this requirement that the source and destination port numbers be the > same, which is a major consideration, that idea leaked into the hmac > implementation which does a: > > DO_HTONS(&port, (unsigned short)protocol_port); > if ((err = blake2s_init_key(&S, key->len, key->value, > BLAKE2S_DIGEST_LENGTH)) < 0) goto fail; > /* Hash the pseudo header. */ > if ((err = blake2s_update(&S, src, 16)) < 0) goto fail; > if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail; > ^^^^^ > if ((err = blake2s_update(&S, dst, 16)) < 0) goto fail; > if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail; > ^^^^ > > the DTLS branch, on the other hand, mandates that ephemeral ports be > used for DTLS communications. Section 2.1 of > https://tools.ietf.org/html/draft-ietf-babel-dtls-02 > > The node acting as DTLS client initiates its DTLS connection from an > ephemeral UDP port. Nodes SHOULD ensure that new client DTLS > connections use different ephemeral ports from recently used > connections to allow servers to differentiate between the new and old > DTLS connections. > > The rub, here, ultimately, is that I could see HMAC being used to > protect multicast and DTLS used to protect unicast, in which case, > allowing for ephemeral src ports generally in the bis version > would be helpful. I do not see how requiring a fixed src port helps > anything? (besides backward compatability) > > Selfishly, I have to admit, that by using an ephemeral udp port for > route transfers and a different, either ephemeral or 6696 for hello/ihu > - fq_codel automagically distinguishes between these two very different > types of traffic and in congested network conditions will drop routes > far more often than hellos. > > A backwards compatible mechanism would be to try hellos/ihus from an > ephemeral port and note when you don't get one back, upon starting an > association. A key indicator to other routers no longer respecting the > fixed src port rule would be recieving such. > > ... > > As a side note, I had suggested using UDP-lite for development purposes > or dtls communications. It's easier to use a different protocol than it > is to get a new port number out of iana... > > I was queried as to why udp-lite, and my answer that I never got around > to saying was that once you have an HMAC, you don't need a CRC, and > also, to my knowledge, udp-lite is very widely deployed, just not used. > It is the same in all other respects to udp. On a single hop over ipv6, > udp-lite "just works" on the versions of linux and bsd I've tried over > the past 5 years. It's impossible to compile out in linux (although > netfilter support for it can be), for example. > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users --00000000000008a5b2057bc1634b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

The Babel over DTLS spec state= s that
- unicast traffic is sent over DTLS, where DTLS client use= s an ephemeral port, and DTLS server uses a well-known port different from = 6696
- multicast traffic still uses 6696 for source and destinati= on

I don't see any issues with protecting Hell= os with HMAC and everything else with DTLS.

David<= /div>

On Wed, Nov 28, = 2018 at 1:56 PM Dave Taht <dave@taht.ne= t> wrote:

Have I been enough of a PITA this month?

Section 4 of rfc6126bis-07 states:

=C2=A0 =C2=A0Both the source and destination UDP port are set to a well-kno= wn port
=C2=A0 =C2=A0number.=C2=A0 A Babel packet MUST be silently ignored unless i= ts source
=C2=A0 =C2=A0address is either a link-local IPv6 address or an IPv4 address=
=C2=A0 =C2=A0belonging to the local network, and its source port is the wel= l-known
=C2=A0 =C2=A0Babel port.

Aside from the fact that all versions of babel prior to now enforced
this requirement that the source and destination port numbers be the
same, which is a major consideration, that idea leaked into the hmac
implementation which does a:

=C2=A0 DO_HTONS(&port, (unsigned short)protocol_port);
=C2=A0 if ((err =3D blake2s_init_key(&S, key->len, key->value, BL= AKE2S_DIGEST_LENGTH)) < 0) goto fail;
=C2=A0 /* Hash the pseudo header. */
=C2=A0 if ((err =3D blake2s_update(&S, src, 16)) < 0) goto fail;
=C2=A0 if ((err =3D blake2s_update(&S, &port, 2)) < 0) goto fail= ;
=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=A0 =C2=A0 =C2=A0 ^^^^^
=C2=A0 if ((err =3D blake2s_update(&S, dst, 16)) < 0) goto fail;
=C2=A0 if ((err =3D blake2s_update(&S, &port, 2)) < 0) goto fail= ;
=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=A0 =C2=A0 =C2=A0 ^^^^

the DTLS branch, on the other hand, mandates that ephemeral ports be
used for DTLS communications. Section 2.1 of
https://tools.ietf.org/html/draft-ietf-babel-dtl= s-02

=C2=A0 =C2=A0The node acting as DTLS client initiates its DTLS connection f= rom an
=C2=A0 =C2=A0ephemeral UDP port.=C2=A0 Nodes SHOULD ensure that new client = DTLS
=C2=A0 =C2=A0connections use different ephemeral ports from recently used =C2=A0 =C2=A0connections to allow servers to differentiate between the new = and old
=C2=A0 =C2=A0DTLS connections.

The rub, here, ultimately, is that I could see HMAC being used to
protect multicast and DTLS used to protect unicast, in which case,
allowing for ephemeral src ports generally in the bis version
would be helpful. I do not see how requiring a fixed src port helps
anything? (besides backward compatability)

Selfishly, I have to admit, that by using an ephemeral udp port for
route transfers and a different, either ephemeral or 6696 for hello/ihu
- fq_codel automagically distinguishes between these two very different
types of traffic and in congested network conditions will drop routes
far more often than hellos.

A backwards compatible mechanism would be to try hellos/ihus from an
ephemeral port and note when you don't get one back, upon starting an association. A key indicator to other routers no longer respecting the
fixed src port rule would be recieving such.

...

As a side note, I had suggested using UDP-lite for development purposes
or dtls communications. It's easier to use a different protocol than it=
is to get a new port number out of iana...

I was queried as to why udp-lite, and my answer that I never got around
to saying was that once you have an HMAC, you don't need a CRC, and
also, to my knowledge, udp-lite is very widely deployed, just not used.
It is the same in all other respects to udp. On a single hop over ipv6,
udp-lite "just works" on the versions of linux and bsd I've t= ried over
the past 5 years. It's impossible to compile out in linux (although
netfilter support for it can be), for example.

_______________________________________________
Babel-users mailing list
Ba= bel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/= cgi-bin/mailman/listinfo/babel-users
--00000000000008a5b2057bc1634b-- From nobody Wed Nov 28 22:12:52 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1899012F1AC for ; Wed, 28 Nov 2018 22:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YVNiMzDQlS-n for ; Wed, 28 Nov 2018 22:12:49 -0800 (PST) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16399130DC1 for ; Wed, 28 Nov 2018 22:12:49 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 72E4221B39; Thu, 29 Nov 2018 06:12:45 +0000 (UTC) From: Dave Taht To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: David Schinazi , babel-users@lists.alioth.debian.org, Barbara Stark , babel@ietf.org References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <87wooxt0s4.fsf@toke.dk> Date: Wed, 28 Nov 2018 22:12:33 -0800 In-Reply-To: <87wooxt0s4.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\= \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of "Wed, 28 Nov 2018 21:17:15 +0100") Message-ID: <87y39cxvhq.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 29 Nov 2018 06:12:51 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > David Schinazi writes: > >>> >>> >>> Why not? If it's not MTI you risk the case where you get to pick between >>> "good performance on weak devices" and "interoperability with RFC-only >>> implementations". >>> >> >> Where are these "RFC-only implementations" of Babel? > > Anyone who does a from-scratch implementation from the RFC, without > being part of the working group process, or looking at the existing > implementations. > >> Remember the IETF does not have a protocol police, MTI is purely >> guidance. Implementors build what they (or their customers) need for >> their use-case. Implementors will add Blake if they need it, not based >> on whether it's MTI or not. It is generally my experience that anything that's a MAY or SHOULD... doesn't get implemented. RIPEMD is an artifact of the original hmac RFC. > > If it's MTI, they can't claim compliance with the RFC until it's in > there. So the "we need this box checked" type of product development > will benefit from this; and while sure, theoretically MTI is a hint, > it's a pretty strong one... > >> Lastly, remember that this is a security solution, so you do NOT want >> to interoperate with a future theoretical implementation, because that >> will not have the keys. Adding any new node in the network will >> require a provisioning step, and that step ensures the new node >> supports the required features. Upgrading any old node to an alternate algorithm is considerably more difficult. 2 HMAC algorithms with a different design history is comforting. > > You can usually control the config, but not necessarily the features > implemented by the device... > > -Toke > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users From nobody Wed Nov 28 22:14:25 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A443B130DC1 for ; Wed, 28 Nov 2018 22:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J0zhhRG4QRmz for ; Wed, 28 Nov 2018 22:14:21 -0800 (PST) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7498912F1AC for ; Wed, 28 Nov 2018 22:14:21 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id AB5C221B39; Thu, 29 Nov 2018 06:14:18 +0000 (UTC) From: Dave Taht To: Mahesh Jethanandani Cc: Dave Taht , Babel at IETF , Keyur Patel , babel-users , Brian Weis References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> Date: Wed, 28 Nov 2018 22:14:07 -0800 In-Reply-To: (Mahesh Jethanandani's message of "Mon, 26 Nov 2018 11:44:23 -0800") Message-ID: <87tvk0xvf4.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] [Babel-users] HMAC Key rotation key format (was ripemd) 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, 29 Nov 2018 06:14:24 -0000 Mahesh Jethanandani writes: > A draft that proposed pair-wise key management was proposed here. It > does not address the question of timestamp, but is something that > could be exchanged as part of key rollover to allow routers to > calculate the delta. Including the original authors of the draft. I'm sorry but adding this level of complexity is not in the cards from my perspective. Layering key exchange over a different out of band medium, being a slip of paper, a telephone call, ssh or https seems saner. > > On Nov 26, 2018, at 6:21 AM, Dave Taht > wrote: > >=20=20=20=20=20 >=20=20=20=20=20 > To me this leaves the biggest problem remaining is key rotation. > Me > being me, and remembering just how hard it was to get dnssec > working > on systems lacking reliable time, > I worry about that part. What we settled on for dnsmasq-dnssec was > to > write the current time to flash every day (or few hours), boot up > without dnssec enabled long enough to > get an ntp server... and rely on key rollover taking hours or days > to > *usually* get a correct result. RTCs with batteries are usually > not > included. >=20=20=20=20=20 > that's still fragile (imagine a power failure lasting days, or a > box > being down for several days for repair. It happens). >=20=20=20=20=20 > In the case of routing... if you don't have the correct time... > and > you can't get a route so you can get the correct time from ntp... > then > what? Do we make GPSes MTI also? >=20=20=20=20=20 > Setting that aside for the moment, having a standardized file > format > for babel keys would be a boon and boost interoperability between > bird/babel and other possible implementations. > You would merely declare a key name in the main conf for bird or > babel, and reference it in a separate file with a format like > this: >=20=20=20=20=20 > KEY START_DATE END_DATE TYPE VALUE > name\wrfc3339\wrfc3339\wsha256|blake2s\wvalue >=20=20=20=20=20 > https://tools.ietf.org/html/rfc3339 >=20=20=20=20=20 > administrators would push out this one standard format file to > routers, strongly suggesting that UTC times be used universally > and > that key rollover should be staged over hours or days lest > connectivity be lost. Other sanity checks like ensuring there is > some > form of persistent and correct time on routers using > authentication > are also needed. >=20=20=20=20=20 > alternatives might include certs and other stuff that bears > drinking about. >=20=20=20=20=20 >=20=20=20=20=20 >=20=20=20=20=20 >=20=20=20=20=20 > --=20 >=20=20=20=20=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 >=20=20=20=20=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel >=20=20=20=20=20 > > Mahesh Jethanandani > mjethanandani@gmail.com > > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users From nobody Wed Nov 28 22:29:06 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6387F130E33 for ; Wed, 28 Nov 2018 22:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oMVvgXl_4HrD for ; Wed, 28 Nov 2018 22:29:03 -0800 (PST) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F1C12F1AC for ; Wed, 28 Nov 2018 22:29:03 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id B9C2B21B39; Thu, 29 Nov 2018 06:29:01 +0000 (UTC) From: Dave Taht To: Juliusz Chroboczek Cc: babel-users@lists.alioth.debian.org, babel@ietf.org References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> Date: Wed, 28 Nov 2018 22:28:50 -0800 In-Reply-To: <8736rl16yj.fsf@taht.net> (Dave Taht's message of "Wed, 28 Nov 2018 08:51:16 -0800") Message-ID: <87lg5cxuql.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 29 Nov 2018 06:29:05 -0000 Dave Taht writes: > Juliusz Chroboczek writes: > >>> Why not? If it's not MTI you risk the case where you get to pick between >>> "good performance on weak devices" and "interoperability with RFC-only >>> implementations". >> >> Is there any evidence that there are devices that can reasonably run Babel >> and that are too weak to use SHA256 for protecting control traffic? >> >> I don't have an ARM device handy right now, but a 450MHz MIPS 24Kc is able >> to SHA256 on the order of 16MB/s. That's 10000 full-size frames per second, >> or on the order of 600000 Babel updates per second. I've been meaning to poke into this a while: https://code.fb.com/connectivity/open-r-open-routing-for-modern-networks/ But I do take your point. It would be good to know that on a given 10,000 route 200 router babel network that hashing overhead accounted for .0X% of the 100% of cpu in use. You are reasonable to assume that sha256 would be low overhead relative to other factors, I think. Still, would like to go measure. Aside: Where does the 300ms figure for re-attempting a challenge and response come from? From nobody Wed Nov 28 22:33:40 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3B6130E12 for ; Wed, 28 Nov 2018 22:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Lu06yw9c7AAK for ; Wed, 28 Nov 2018 22:33:36 -0800 (PST) Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78EAE130E35 for ; Wed, 28 Nov 2018 22:33:35 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 59CEA21B39; Thu, 29 Nov 2018 06:33:33 +0000 (UTC) From: Dave Taht To: David Schinazi Cc: Juliusz Chroboczek , babel-users@lists.alioth.debian.org, babel@ietf.org References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> <87o9a8zx1a.fsf_-_@taht.net> Date: Wed, 28 Nov 2018 22:33:22 -0800 In-Reply-To: (David Schinazi's message of "Wed, 28 Nov 2018 14:49:52 -0800") Message-ID: <87h8g0xuj1.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] DTLS and hmac co-existence 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, 29 Nov 2018 06:33:39 -0000 David Schinazi writes: > Hi Dave, > > The Babel over DTLS spec states that > - unicast traffic is sent over DTLS, where DTLS client uses an > ephemeral port, and DTLS server uses a well-known port different from > 6696 > - multicast traffic still uses 6696 for source and destination > > I don't see any issues with protecting Hellos with HMAC and everything > else with DTLS. Yes, the current spec will work. I was trying to solve a different rate control problem by allowing ephemeral ports elsewhere. a better method to negotiate a more relaxed approach to using ephemeral ports, and not needed to be in the spec, either, would be to try an ack request from an ephemeral port. Has anyone put in for an official dtls port number from IANA? > > David > > On Wed, Nov 28, 2018 at 1:56 PM Dave Taht wrote: > > Have I been enough of a PITA this month? > > Section 4 of rfc6126bis-07 states: > > Both the source and destination UDP port are set to a well-known > port > number. A Babel packet MUST be silently ignored unless its source > address is either a link-local IPv6 address or an IPv4 address > belonging to the local network, and its source port is the > well-known > Babel port. > > Aside from the fact that all versions of babel prior to now > enforced > this requirement that the source and destination port numbers be > the > same, which is a major consideration, that idea leaked into the > hmac > implementation which does a: > > DO_HTONS(&port, (unsigned short)protocol_port); > if ((err = blake2s_init_key(&S, key->len, key->value, > BLAKE2S_DIGEST_LENGTH)) < 0) goto fail; > /* Hash the pseudo header. */ > if ((err = blake2s_update(&S, src, 16)) < 0) goto fail; > if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail; > ^^^^^ > if ((err = blake2s_update(&S, dst, 16)) < 0) goto fail; > if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail; > ^^^^ > > the DTLS branch, on the other hand, mandates that ephemeral ports > be > used for DTLS communications. Section 2.1 of > https://tools.ietf.org/html/draft-ietf-babel-dtls-02 > > The node acting as DTLS client initiates its DTLS connection from > an > ephemeral UDP port. Nodes SHOULD ensure that new client DTLS > connections use different ephemeral ports from recently used > connections to allow servers to differentiate between the new and > old > DTLS connections. > > The rub, here, ultimately, is that I could see HMAC being used to > protect multicast and DTLS used to protect unicast, in which case, > allowing for ephemeral src ports generally in the bis version > would be helpful. I do not see how requiring a fixed src port > helps > anything? (besides backward compatability) > > Selfishly, I have to admit, that by using an ephemeral udp port > for > route transfers and a different, either ephemeral or 6696 for > hello/ihu > - fq_codel automagically distinguishes between these two very > different > types of traffic and in congested network conditions will drop > routes > far more often than hellos. > > A backwards compatible mechanism would be to try hellos/ihus from > an > ephemeral port and note when you don't get one back, upon starting > an > association. A key indicator to other routers no longer respecting > the > fixed src port rule would be recieving such. > > ... > > As a side note, I had suggested using UDP-lite for development > purposes > or dtls communications. It's easier to use a different protocol > than it > is to get a new port number out of iana... > > I was queried as to why udp-lite, and my answer that I never got > around > to saying was that once you have an HMAC, you don't need a CRC, > and > also, to my knowledge, udp-lite is very widely deployed, just not > used. > It is the same in all other respects to udp. On a single hop over > ipv6, > udp-lite "just works" on the versions of linux and bsd I've tried > over > the past 5 years. It's impossible to compile out in linux > (although > netfilter support for it can be), for example. > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users > From nobody Thu Nov 29 10:56:27 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F2B130E66 for ; Thu, 29 Nov 2018 10:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgdiD1qlhMSn for ; Thu, 29 Nov 2018 10:56:23 -0800 (PST) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (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 AE595130E64 for ; Thu, 29 Nov 2018 10:56:23 -0800 (PST) Received: by mail-qk1-x744.google.com with SMTP id y16so1706975qki.7 for ; Thu, 29 Nov 2018 10:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aHlTyToNJ1oItMauTeMYUiIg++PjDERaq8axGTG+//E=; b=ZxJ7KOy/lHLMTYDeJek8orbwMiZWs8NdrwWcfrjkNChdmesQ6DNaPuGmWB+xlfTLPA XdgwJddWMtVBc3TlmeK8rLSD0ee3ORRip5FoH7ermEZYEymOrjnf1yVwq1+G5sxFqktW R/dRD1J6W60JWDV+398gAMU0Xgy18hKrrvBXJU28+L74xxjdxILobcAOtUkxyxdU/s9G ka2r7nzjWPtO4xvYHS/URL8dy89ffrGe70h1MsU8SEht2miJ3l1QTgmDYuDm6ECQ65SC r6bx20lyOMEQj1cLgIGsE3HJKrWiWHKiRAgnoSwLkF+F3CABeqEKkRh+jKZ93WByHaFt HuqA== 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=aHlTyToNJ1oItMauTeMYUiIg++PjDERaq8axGTG+//E=; b=R6ZyvARrgnZVjmSc24aGs52irfZGx5ErH7TZNeiHzSJX3CzNbmNb6PPi3NnhO/e+hv 4KV7AoJrnxdORbHUIAYMfAyVYI3ut4WSbGxOXbnp0IlaPXSIJusrrFZdaeZx0aN7azli +KX7XDomYDMwfT6MM2wEXxfehoSLPSDjc/dejLCBOBpVSXe5QSvRrn9gMEJDsZQ4Zul+ rWfi9IzcQNqFvlMSqxz203rkahFck/CCwpc/7xJBHPOJKlCV2yjbYyEUocnpYXKBRDL3 ZU4vlXG5aSTNYUggRaxFzHc7gRhBNdomBKYmVokqlFL0iGA7F6XB18zvA7zLvP7+CR1X lojA== X-Gm-Message-State: AA+aEWaXxaIZgRrLwYleBTHP4mCCVOtAeivONuVhn5Hw3BTAiF/EiuyX 6RmTLP23LMvJ5JdEJx1Ls6BYJ+Gamfn4YpoFokVWqw== X-Google-Smtp-Source: AFSGD/UPJTMRoW3M+Q3sPUMmZJZlE8vVF7MFGM5Jk86Y9bwq0XX1jWzyLKkpQ90USrW6tjkDajd2LFTFpao+e4PMPO8= X-Received: by 2002:a37:c12:: with SMTP id 18mr2376835qkm.317.1543517782764; Thu, 29 Nov 2018 10:56:22 -0800 (PST) MIME-Version: 1.0 References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <87tvk0xvf4.fsf@taht.net> In-Reply-To: <87tvk0xvf4.fsf@taht.net> From: Ted Lemon Date: Thu, 29 Nov 2018 13:55:46 -0500 Message-ID: To: =?UTF-8?Q?Dave_T=C3=A4ht?= Cc: Mahesh Jethanandani , keyur@arrcus.com, bew@cisco.com, Dave Taht , Babel at IETF , babel-users@lists.alioth.debian.org Content-Type: multipart/alternative; boundary="0000000000002585b7057bd23ddd" Archived-At: Subject: Re: [babel] [Babel-users] HMAC Key rotation key format (was ripemd) 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, 29 Nov 2018 18:56:26 -0000 --0000000000002585b7057bd23ddd Content-Type: text/plain; charset="UTF-8" On Thu, Nov 29, 2018 at 1:14 AM Dave Taht wrote: > Mahesh Jethanandani writes: > > A draft that proposed pair-wise key management was proposed here. It > > does not address the question of timestamp, but is something that > > could be exchanged as part of key rollover to allow routers to > > calculate the delta. Including the original authors of the draft. > > I'm sorry but adding this level of complexity is not in the cards > from my perspective. Layering key exchange over a different out of band > medium, being a slip of paper, a telephone call, ssh or https seems > saner. FWIW, for homenet the thought was to use HNCP to distribute keys amongst routers. This doesn't solve the general problem, but illustrates your point, Dave, that this is something that can be provisioned out of band. (In the HNCP case we're talking about public keys for DTLS, not shared secrets, of course). This seems like a better choice than a complicated pairwise key management strategy for HMAC. --0000000000002585b7057bd23ddd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 29= , 2018 at 1:14 AM Dave Taht <dave@taht.= net> wrote:
Mahesh Jethanand= ani <mjetha= nandani@gmail.com> writes:
> A draft that proposed pair-wise k= ey management was proposed here. It
> does not address the question of timestamp, but is something that
> could be exchanged as part of key rollover to allow routers to
> calculate the delta. Including the original authors of the draft.

I'm sorry but adding this level of complexity is not in the cards
from my perspective. Layering key exchange over a different out of band
medium, being a slip of paper, a telephone call, ssh or https seems
saner.

FWIW, for homenet the thought was to= use HNCP to distribute keys amongst routers.=C2=A0 =C2=A0This doesn't = solve the general problem, but illustrates your point, Dave, that this is s= omething that can be provisioned out of band.=C2=A0 (In the HNCP case we= 9;re talking about public keys for DTLS, not shared secrets, of course).=C2= =A0 =C2=A0This seems like a better choice than a complicated pairwise key m= anagement strategy for HMAC.
--0000000000002585b7057bd23ddd-- From nobody Fri Nov 30 00:48:29 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F3D12F18C for ; Fri, 30 Nov 2018 00:48:27 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnCFESgvPO2v for ; Fri, 30 Nov 2018 00:48:23 -0800 (PST) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A071130934 for ; Fri, 30 Nov 2018 00:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=j2oN2mFXlun2dyW7HmldST9JLoQGhmn9q4YowPxQVIg=; b=pivbJKGXt5ntvH/OT28xk0aZ/W DQVMA2dHWfLLT+JlYXBRYJIvwE50XxxkIPbUsFkfzTltfDhmiHmBv/quQJQ47yvTCBqEn9REDkzsS oimEyh/0gQrjln11pmhWOaQrII8wK2rv2eDVg31hIUf23vtm1rz/fV6Mlw3hNiA4nsamemeago2IY rnwy3mS7d44prtgZtu6L+0IMCXQITAavxcYisD6G5NOXb5SK3nkktHTjRJu0duetslAKLo6v7+Q1X payTfA4DmdVlGa643aYnDP6MWP7F/UsG13cCEtUYm/QlMC9GkqLknBqHuFIcO/lvsrzLAE3C16aaU tj9IaZNA==; Received: from 91-155-69-202.elisa-laajakaista.fi ([91.155.69.202] helo=himawari.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gSeT8-00025Y-W8; Fri, 30 Nov 2018 10:48:15 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Markus Stenberg In-Reply-To: <87lg5cxuql.fsf@taht.net> Date: Fri, 30 Nov 2018 10:48:14 +0200 Cc: Juliusz Chroboczek , babel-users , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C6B19AE-EAA7-4329-A364-8E4C059DAC01@iki.fi> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> <87lg5cxuql.fsf@taht.net> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3445.101.1) X-SA-Exim-Connect-IP: 91.155.69.202 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 30 Nov 2018 08:48:27 -0000 Here's some raw numbers (clickbait): - my Macbook (sanity check) - Turris Omnia (2016 highend) - Buffalo WZR-600DHP (2012 midend) https://github.com/fingon/go-hashperf TL;DR (probably the interesting part): 2012 midend home router does 40 bytes: - 37.5k pps of SHA256 - bit over 40k pps of Blake2B - 91k pps of Blake2S Setup overhead disappears both in SHA256 and Blake2 at ~500 byte mark = (500 and 1200 bytes roughly equal MB/s); with 200 byte packets setup = still wastes ~1/4 of performance (both SHA256 and Blake2) and even more = with 40 byte packets. With these numbers, I withdraw my support of including anything else = than SHA256 as MTI. I think specifying Blake2B or 2S as well makes sense = (mostly for crypto robustness reasons for having alternative that is = specified) but making it MAY-SHOULD seems sensible to me. The code is there, go ahead to test on your own routers if you care. I = didn't bother testing arm64 in the end, as those are even faster than = arm (the ridiculous blake2s number of 460k pps for Blake2s on Turris = Omnia convinced me that it is not really worth it to test on faster = hardware). -Markus= From nobody Fri Nov 30 02:41:40 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA8B130DD2 for ; Fri, 30 Nov 2018 02:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii2xl1I1aIYJ for ; Fri, 30 Nov 2018 02:41:35 -0800 (PST) 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 9623412D4EC for ; Fri, 30 Nov 2018 02:41:35 -0800 (PST) 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=1543574462; bh=AnYFgSoZJaFmbrN77fD3bwKfHHAiwypLAtDN08MS+Rs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PiY9iRuxcCNQHQo7zmVHeeSqHExDRtiuUpQulZWmyHy7DVFA7Q4vhcjtEU1Log9Gr wbd6mci7OdVQM3T1HMbImA43o/n0ecsKGVEyXt7CNA9U/xjLqQaf5XmfwUI062199P t2eXpd6vKPr2M9DTSDIrpssM+gRrH/ijjFDZ9AD62ngrya1/kQEeuPy/4FeLKmE0mk jVsQt6W+Ptd3bOngUTTg/fyrsk274bECEYCPKsTNVLwiynLyasVjlGMjzmKmo6J/ef 8jHBg47rahGLNl/8tAP3alPvgRggm8LGtAKr/uFr3E3DMAdkx06FC/5hBSLoBSbX1G H0EAQ/lUqAf+g== To: Markus Stenberg , Dave =?utf-8?Q?T=C3=A4ht?= Cc: babel@ietf.org, babel-users In-Reply-To: <1C6B19AE-EAA7-4329-A364-8E4C059DAC01@iki.fi> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> <87lg5cxuql.fsf@taht.net> <1C6B19AE-EAA7-4329-A364-8E4C059DAC01@iki.fi> Date: Fri, 30 Nov 2018 11:41:00 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87woouq24j.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] rather than ripemd160... 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, 30 Nov 2018 10:41:39 -0000 Markus Stenberg writes: > Here's some raw numbers (clickbait): > > - my Macbook (sanity check) > - Turris Omnia (2016 highend) > - Buffalo WZR-600DHP (2012 midend) > > https://github.com/fingon/go-hashperf > > TL;DR (probably the interesting part): > > 2012 midend home router does 40 bytes: > - 37.5k pps of SHA256 > - bit over 40k pps of Blake2B > - 91k pps of Blake2S That's is awesome, thanks for doing this! > Setup overhead disappears both in SHA256 and Blake2 at ~500 byte mark > (500 and 1200 bytes roughly equal MB/s); with 200 byte packets setup > still wastes ~1/4 of performance (both SHA256 and Blake2) and even > more with 40 byte packets. > > With these numbers, I withdraw my support of including anything else > than SHA256 as MTI. I think specifying Blake2B or 2S as well makes > sense (mostly for crypto robustness reasons for having alternative > that is specified) but making it MAY-SHOULD seems sensible to me. I can probably live with that :) > The code is there, go ahead to test on your own routers if you care. I > didn't bother testing arm64 in the end, as those are even faster than > arm (the ridiculous blake2s number of 460k pps for Blake2s on Turris > Omnia convinced me that it is not really worth it to test on faster > hardware). Yeah, 460k pps ought to be enough for everyone ;) -Toke From nobody Fri Nov 30 03:24:07 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60A4130DD2 for ; Fri, 30 Nov 2018 03:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1PELCYlJmBF for ; Fri, 30 Nov 2018 03:24:02 -0800 (PST) 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 449E812D4EC for ; Fri, 30 Nov 2018 03:24:02 -0800 (PST) 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 wAUBNsCM023586; Fri, 30 Nov 2018 12:23:54 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 63BF429F11; Fri, 30 Nov 2018 12:24:00 +0100 (CET) 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 dTUlYuLTXkAL; Fri, 30 Nov 2018 12:23:57 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8534329F08; Fri, 30 Nov 2018 12:23:52 +0100 (CET) Date: Fri, 30 Nov 2018 12:23:52 +0100 Message-ID: <87in0e6c6v.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Markus Stenberg , Dave =?ISO-8859-1?Q?T=E4ht?= , babel-users , babel@ietf.org In-Reply-To: <87woouq24j.fsf@toke.dk> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> <87lg5cxuql.fsf@taht.net> <1C6B19AE-EAA7-4329-A364-8E4C059DAC01@iki.fi> <87woouq24j.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 30 Nov 2018 12:23:54 +0100 (CET) X-Miltered: at korolev with ID 5C011DCA.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C011DCA.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 : 5C011DCA.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] Blake2S, blake2B or neither? [was: rather than ripemd160...] 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, 30 Nov 2018 11:24:05 -0000 >> With these numbers, I withdraw my support of including anything else >> than SHA256 as MTI. I think specifying Blake2B or 2S as well makes >> sense (mostly for crypto robustness reasons for having alternative >> that is specified) but making it MAY-SHOULD seems sensible to me. > I can probably live with that :) Excellent, it looks like we're converging. Thanks to both of you for the informative and kind discussion. At this stage, I see four possibilities: (1) leave the document as it is; (2) add a mention that implementation of Blake2S is RECOMMENDED (SHOULD); (3) add a mention that implementation of Blake2B is RECOMMENDED; (4) add a mention that implementation of both 2B and 2S is RECOMMENDED. I am in favour of (1), since I am convinced that SHA256 is fast enough for all reasonable devices. (2) makes sense to me, and I won't oppose it. I'll need some convincing in order to do (3) or (4), since Blake2B does not appear bring any significant speed advantage over SHA256. In either case, I'm planning to implement SHA256, Blake2B and Blake2S in the reference implementation. -- Juliusz From nobody Fri Nov 30 05:23:38 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DACC1292AD for ; Fri, 30 Nov 2018 05:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtHx1Xe971Hf for ; Fri, 30 Nov 2018 05:23:34 -0800 (PST) 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 BDB71127333 for ; Fri, 30 Nov 2018 05:23:33 -0800 (PST) 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=1543584166; bh=UK0z5kc+1Hj/OQBnFx1GjMMGrEVfwYC6rvku7AKhH2U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=b0XgvlWqaC+2Mz9B3SsYXxQS5k+5aMNvIU0tdR2O3Dqvk/FygZ25R9brr1PsmGxoo cwycPdPfuiEejV+mgSQdutSP8VKkWxQNY95uS0jRl5WwUtuE8cfeyo5A2eXRN8Wsr6 8w6lirt5nzTGXj1KY5knI547epX9eenmg7MOQPUpkp3eJ0mZu5fmfwCmJabJye2+Wj VxxH9eFBL7ai2bqBKO2jHh7SYhwvbzoShXgL397SdsWpvRdt0Zco7mc2Em2206BxQt v3A9BhqSjv31erdMwzJEJw6Z6ffraAtcdX/ZH0yF9G0k8rt44nc5QPWhE7tBJtpZUI 9euh9nskezz+g== To: Juliusz Chroboczek Cc: Markus Stenberg , Dave =?utf-8?Q?T=C3=A4ht?= , babel-users , babel@ietf.org In-Reply-To: <87in0e6c6v.wl-jch@irif.fr> References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> <87lg5cxuql.fsf@taht.net> <1C6B19AE-EAA7-4329-A364-8E4C059DAC01@iki.fi> <87woouq24j.fsf@toke.dk> <87in0e6c6v.wl-jch@irif.fr> Date: Fri, 30 Nov 2018 14:22:44 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87o9a6pumz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Blake2S, blake2B or neither? [was: rather than ripemd160...] 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, 30 Nov 2018 13:23:36 -0000 Juliusz Chroboczek writes: >>> With these numbers, I withdraw my support of including anything else >>> than SHA256 as MTI. I think specifying Blake2B or 2S as well makes >>> sense (mostly for crypto robustness reasons for having alternative >>> that is specified) but making it MAY-SHOULD seems sensible to me. > >> I can probably live with that :) > > Excellent, it looks like we're converging. Thanks to both of you for the > informative and kind discussion. > > At this stage, I see four possibilities: > > (1) leave the document as it is; > (2) add a mention that implementation of Blake2S is RECOMMENDED (SHOULD); > (3) add a mention that implementation of Blake2B is RECOMMENDED; > (4) add a mention that implementation of both 2B and 2S is RECOMMENDED. > > I am in favour of (1), since I am convinced that SHA256 is fast enough for > all reasonable devices. (2) makes sense to me, and I won't oppose it. > I'll need some convincing in order to do (3) or (4), since Blake2B does > not appear bring any significant speed advantage over SHA256. I'm in favour of (2). > In either case, I'm planning to implement SHA256, Blake2B and Blake2S in > the reference implementation. Cool. I'll do the same in Bird, then :) -Toke From nobody Fri Nov 30 05:39:50 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71E11200B3 for ; Fri, 30 Nov 2018 05:39:47 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=kapsi.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhDFQzPTc2B0 for ; Fri, 30 Nov 2018 05:39:45 -0800 (PST) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CF3123FFD for ; Fri, 30 Nov 2018 05:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=NTpvfRipsk7kDtMEYcsXrNb40Grq744V3S4wiTgK72g=; b=nYxG8aRDWaEzG13R/w0yI4p6El wdOMlTgaW4647HuGdPp/fx3eIBxjeTpQNhY47c4UQ798YgFwpdO4OOTG1aFSmY4aB2B8TigzSg6+Z lQkKw7/SV778ZIjb2YBzbxnpvOsDO1BHb1ISptZSH8N3zSDrG1fIsJ3kWM4qRrOf9drNdTw8KNhLq CSYzblAK2HRyn/vINlgkQD2iej/QmFV6MIRcrAN1iQzv+N/4eX960/ZmVwHDMapoftHXvP8+uLSL9 slM7VvP2Ezd8xkZQjm1p1it6H1BAiDSGSWQ0HXmyRGmrAegG0Aq7aGVFoOznuOOBsLFi6viYJbIgz 1uvcVvMA==; Received: from 91-155-69-202.elisa-laajakaista.fi ([91.155.69.202] helo=yuri.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gSj18-0006Ob-Va; Fri, 30 Nov 2018 15:39:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Markus Stenberg In-Reply-To: <87in0e6c6v.wl-jch@irif.fr> Date: Fri, 30 Nov 2018 15:39:38 +0200 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , =?utf-8?Q?Dave_T=C3=A4ht?= , Babel at IETF , babel-users Content-Transfer-Encoding: quoted-printable Message-Id: References: <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <87o9a9v3c6.fsf@toke.dk> <875zwhxv28.wl-jch@irif.fr> <8736rl16yj.fsf@taht.net> <87lg5cxuql.fsf@taht.net> <1C6B19AE-EAA7-4329-A364-8E4C059DAC01@iki.fi> <87woouq24j.fsf@toke.dk> <87in0e6c6v.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.101.1) X-SA-Exim-Connect-IP: 91.155.69.202 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Blake2S, blake2B or neither? [was: rather than ripemd160...] 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, 30 Nov 2018 13:39:48 -0000 > On 30 Nov 2018, at 13.23, Juliusz Chroboczek wrote: >>> With these numbers, I withdraw my support of including anything else >>> than SHA256 as MTI. I think specifying Blake2B or 2S as well makes >>> sense (mostly for crypto robustness reasons for having alternative >>> that is specified) but making it MAY-SHOULD seems sensible to me. >> I can probably live with that :) >=20 > Excellent, it looks like we're converging. Thanks to both of you for = the > informative and kind discussion. >=20 > At this stage, I see four possibilities: >=20 > (1) leave the document as it is; > (2) add a mention that implementation of Blake2S is RECOMMENDED = (SHOULD); > (3) add a mention that implementation of Blake2B is RECOMMENDED; > (4) add a mention that implementation of both 2B and 2S is = RECOMMENDED. >=20 > I am in favour of (1), since I am convinced that SHA256 is fast enough = for > all reasonable devices. (2) makes sense to me, and I won't oppose it. > I'll need some convincing in order to do (3) or (4), since Blake2B = does > not appear bring any significant speed advantage over SHA256. >=20 > In either case, I'm planning to implement SHA256, Blake2B and Blake2S = in > the reference implementation. I do not actually recommend 2B based on the numbers. By looking at them, = you notice that the setup time for 2B is higher and even on 64bit = platform the gain is not insane even on large operations (25%ish, = perhaps). -2BP is what I have and will recommend for large bulk hashing = (-P variant allows for paralllelization of hashing to multiple cores), = but for smaller stuff it seems Blake2S is faster on both 32 and 64bit. As they are all based on same cryptographic base, it is likely that if = weakness is found in one, it is present in others. That said, as BLAKE = algorithm was at the time of SHA-3 contest analyzed to be strictly = superior to SHA-2 in some features, it seems unlikely. But you never = know. The above discussion cuts out options 3 and 4 for me. I am mostly indifferent between 1 and 2; SHA256 (especially with = hardware acceleration) is probably faster than Blake (even with just = Intel optimized assembler it is 60-70% of Blake 2B), and if we=E2=80=99re = talking millions of pps (acceleration present) it is entirely academic = anyway for a routing protocol. The tinfoil hat argument for 2 is that it = provides fallback if SHA256 breaks down somehow in the future. So I have = SLIGHT preference for 2 but am happy enough with 1 as well. Cheers, -Markus=