From nobody Sun Aug 2 12:08:08 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373D43A0AE5 for ; Sun, 2 Aug 2020 12:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s10glowHzB5z for ; Sun, 2 Aug 2020 12:08:05 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAED3A0AE3 for ; Sun, 2 Aug 2020 12:08:04 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 072J80am027430; Sun, 2 Aug 2020 21:08:00 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id EBA19BAE82; Sun, 2 Aug 2020 21:08:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ZugTU_oe_J85; Sun, 2 Aug 2020 21:07:59 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BAD56BAE80; Sun, 2 Aug 2020 21:07:59 +0200 (CEST) Date: Sun, 02 Aug 2020 21:07:59 +0200 Message-ID: <87pn88kgs0.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: =?ISO-8859-1?Q?Th=E9ophile?= Bastian , Margaret User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 02 Aug 2020 21:08:01 +0200 (CEST) X-Miltered: at korolev with ID 5F270F10.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F270F10.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 : 5F270F10.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] About ICMP and unnumbered routers X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 19:08:07 -0000 Dear all, This mail is about the consequences of draft-bastian-babel-v4ov6-00 on ICMPv4 generation. At last week's meeting, Margaret kindly pointed out that we didn't do our homework, and that we didn't consider how ICMPv4 is sent out when the sending router has no IPv4 addresses. I've looked at a few RFCs, and here are my tentative conclusions. RFC 1812 Section 2.2.7 says: In this scheme, a router that has unnumbered point to point lines also has a special IP address, called a router-id in this memo. The router-id is one of the router's IP addresses (a router is required to have at least one IP address). This router-id is used as if it is the IP address of all unnumbered interfaces. So it looks like it was decided back in 1995 that all IPv4 routers need at least one IPv4 address. Much as I tried, I couldn't find anything that would relax this requirement. As expected, when an ICMPv4 packet is sent over an unnumbered interface, the distinguished "router-id" address is used as the source address: the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted. If the interface has no IP addresses associated with it, the router's router-id (see Section [5.2.5]) is used instead. (This appears to be a typo -- there's nothing relevant in Section 5.2.5.) Interestingly, there appears to be nothing in RFC 1812 that specifies that the router-id is globally unique; thus, what we could do would be to put the same IPv4 address on all routers. This would make traceroute a little confusing (RFC 5837 might help), but it would solve both the problem with ICMPv4 blackholes and compliance with RFC 1812. In the light of the above, and in the immortal words of Lenin, what shall we do? 1. Pick a private IPv4 (say 10.42.42.42) and put it on the loopback interface of all unnumbered routers. 2. Request a dedicated IPv4 address (the "all-routers anycast address") to be used as the loopback address of unnumbered routers. 3. Update RFC 1812 to allow unnumbered routers and 0.0.0.0 as the source address of ICMPv4 packets. I'm interested in the comments of wise people. -- Juliusz From nobody Sun Aug 2 17:30:23 2020 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 B65603A0E30; Sun, 2 Aug 2020 17:30:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <159641462168.10395.14438024251887067236@ietfa.amsl.com> Date: Sun, 02 Aug 2020 17:30:21 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-18.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 00:30:22 -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-18.txt Pages : 69 Date : 2020-08-02 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 2 17:52:44 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581EC3A0E72 for ; Sun, 2 Aug 2020 17:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPltqfJfkYD2 for ; Sun, 2 Aug 2020 17:52:41 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BEC3A0E71 for ; Sun, 2 Aug 2020 17:52:41 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id t6so24911218ljk.9 for ; Sun, 02 Aug 2020 17:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=91zNVz68gxsAbjU9Yeqd+/t2ZugeRTGKIc4hxrr27Rw=; b=f9WqMsMOyya4G77/7wS2MipZ1BZ3dg9gOeWnpslaMpizjhxEPmUQkp1+QDxYRydOY0 8b1KpooS/MbG2Mawtz552pl7a3IwvyK9Kxc5fTIzu/zYoP4uev6TlHqoOS4PbBnBae9i j2gEJP/Kk2q+HU88pUgPQThDzVjbEu3t8T9EHdCTqO4gg9NMVJl/ngkGVAM+t+egwE3+ 1eRFb0SRdZ9BzdpFJFBOqv82itJ3nSjXjolSsjore5YEeH4UGp8fBfiLSVF6YzF3AJxd LEusDVN6tau939Kd6jcrGqHAW1Btb+5q1CHUNWQ9V3J8NiPxz27BldM4tQeWdwG1d0HZ wiBw== 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=91zNVz68gxsAbjU9Yeqd+/t2ZugeRTGKIc4hxrr27Rw=; b=DMVm/guc2siCoDErQ1k66VuzaAlyGaDZyNIGup7o3xuTHo6Dl7Z4dfUfzUgI23p1PF r9+QRbcGuRDcC+W/WAtdMeMADKEpccfn7rTk6yANUmpjV1ykgPvrXPiOOmarOhQU1ApP c7HAhj4Kwi7qFeUeJXvTcm/FGDUAE2l/vYoQgeyZzLNDp+wdxo4o12Atz7yE0s9Phrm0 TCDBLDNEy/JHW8vLnWi1q4dO44s689xuiC0M1/u5GcviGt9x5lfLVdiX1BwAZx9X+K2Q 4gHD7xeTKlplkIOlEHnaMRDPDONp7ztSWW0HpQBDuBZ6jzP7gFfQe2CMcjO+GPRjhBVo dPwg== X-Gm-Message-State: AOAM530yajJnDDDLRMSrjAfOBWXm/kipD3DZX8vJRSQy3GTLVSJc7ZYA PExrL26Ky8C2+KQHtORlyjfCyu3Wu1kCIktR5pU= X-Google-Smtp-Source: ABdhPJxXgIUJCa1LRbWuN/UCLt6JA7qvjVJLNFf3QzuMu7upS8EswKUzom/s6054t9arpSkWmWS1zy04YIhviAxwoPs= X-Received: by 2002:a2e:86d5:: with SMTP id n21mr1447556ljj.188.1596415959464; Sun, 02 Aug 2020 17:52:39 -0700 (PDT) MIME-Version: 1.0 References: <87pn88kgs0.wl-jch@irif.fr> In-Reply-To: <87pn88kgs0.wl-jch@irif.fr> From: David Schinazi Date: Sun, 2 Aug 2020 17:52:28 -0700 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , Margaret , =?UTF-8?Q?Th=C3=A9ophile_Bastian?= Content-Type: multipart/alternative; boundary="0000000000002d7e6205abee8ecd" Archived-At: Subject: Re: [babel] About ICMP and unnumbered routers X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 03 Aug 2020 00:52:43 -0000 --0000000000002d7e6205abee8ecd Content-Type: text/plain; charset="UTF-8" I don't know if I qualify as a "wise person", but I have comments :-) I may have found a solution from 4rd. They reserved an "IPv4 dummy address" specifically for the purpose of filling in the source address of ICMPv4 packets: https://tools.ietf.org/html/rfc7600#section-4.8 (Text copied below for convenience) I think this might suit our needs? Cheers, David 4.8. Tunnel-Generated ICMPv6 Error Messages If a Tunnel packet is discarded on its way across a 4rd domain because of an unreachable destination, an ICMPv6 error message is returned to the IPv6 source. For the IPv4 source of the discarded packet to be informed of packet loss, the ICMPv6 message has to be converted into an ICMPv4 message. R-22: If a CE or BR receives an ICMPv6 error message [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC792]. This packet MUST contain the first 8 octets of the discarded packet's IP payload. The reserved IPv4 dummy address (192.0.0.8/32; see Section 6) MUST be used as its source address. As described in [RFC6145], ICMPv6 Type = 1 and Code = 0 (Destination Unreachable, No route to destination) MUST be translated into ICMPv4 Type = 3 and Code = 0 (Destination Unreachable, Net unreachable), and ICMPv6 Type = 3 and Code = 0 (Time Exceeded, Hop limit exceeded in transit) MUST be translated into ICMPv4 Type = 11 and Code = 0 (Time Exceeded, time to live exceeded in transit). On Sun, Aug 2, 2020 at 12:08 PM Juliusz Chroboczek wrote: > Dear all, > > This mail is about the consequences of draft-bastian-babel-v4ov6-00 on > ICMPv4 generation. > > At last week's meeting, Margaret kindly pointed out that we didn't do our > homework, and that we didn't consider how ICMPv4 is sent out when the > sending router has no IPv4 addresses. I've looked at a few RFCs, and here > are my tentative conclusions. > > RFC 1812 Section 2.2.7 says: > > In this scheme, a router that > has unnumbered point to point lines also has a special IP address, > called a router-id in this memo. The router-id is one of the > router's IP addresses (a router is required to have at least one IP > address). This router-id is used as if it is the IP address of all > unnumbered interfaces. > > So it looks like it was decided back in 1995 that all IPv4 routers need at > least one IPv4 address. Much as I tried, I couldn't find anything that > would relax this requirement. As expected, when an ICMPv4 packet is sent > over an unnumbered interface, the distinguished "router-id" address is > used as the source address: > > the IP source address in an ICMP message originated by the router MUST > be one of the IP addresses associated with the physical interface over > which the ICMP message is transmitted. If the interface has no IP > addresses associated with it, the router's router-id (see Section > [5.2.5]) is used instead. > > (This appears to be a typo -- there's nothing relevant in Section 5.2.5.) > > Interestingly, there appears to be nothing in RFC 1812 that specifies that > the router-id is globally unique; thus, what we could do would be to put > the same IPv4 address on all routers. This would make traceroute a little > confusing (RFC 5837 might help), but it would solve both the problem with > ICMPv4 blackholes and compliance with RFC 1812. > > In the light of the above, and in the immortal words of Lenin, what shall > we do? > > 1. Pick a private IPv4 (say 10.42.42.42) and put it on the loopback > interface of all unnumbered routers. > > 2. Request a dedicated IPv4 address (the "all-routers anycast address") to > be used as the loopback address of unnumbered routers. > > 3. Update RFC 1812 to allow unnumbered routers and 0.0.0.0 as the source > address of ICMPv4 packets. > > I'm interested in the comments of wise people. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --0000000000002d7e6205abee8ecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't know if I qualify as a "wise person"= , but I have comments :-)

I may have found a solution fr= om 4rd. They reserved an
"IPv4 dummy address" specifica= lly for the purpose of
filling in the source address of ICMPv4 pa= ckets:

https://tools.ietf.org/html/rfc7600#section-4.8
(Text copied below for convenience)

I = think this might suit our needs?

Cheers,
David


4.8.=C2=A0 Tunnel-Generated ICMPv6 Erro= r Messages

=C2=A0 =C2=A0If a Tunnel packet is discarded on its way a= cross a 4rd domain
=C2=A0 =C2=A0because of an unreachable destination, a= n ICMPv6 error message is
=C2=A0 =C2=A0returned to the IPv6 source.=C2= =A0 For the IPv4 source of the discarded
=C2=A0 =C2=A0packet to be infor= med of packet loss, the ICMPv6 message has to be
=C2=A0 =C2=A0converted = into an ICMPv4 message.

=C2=A0 =C2=A0R-22: If a CE or BR receives an= ICMPv6 error message [RFC4443], it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MU= ST synthesize an ICMPv4 error packet [RFC792].=C2=A0 This packet
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST contain the first 8 octets of the discarded= packet's IP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0payload.=C2=A0 The re= served IPv4 dummy address (192.0.0.8/32= ; see
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 6) MUST be used as its s= ource address.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As described in [RF= C6145], ICMPv6 Type =3D 1 and Code =3D 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(Destination Unreachable, No route to destination) MUST be
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0translated into ICMPv4 Type =3D 3 and Code =3D 0 (D= estination
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unreachable, Net unreachabl= e), and ICMPv6 Type =3D 3 and Code =3D 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(Time Exceeded, Hop limit exceeded in transit) MUST be
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0translated into ICMPv4 Type =3D 11 and Code =3D 0 (Time= Exceeded,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time to live exceeded in tr= ansit).


On Sun, Aug 2, 2020 at 12:08 PM Juliusz Chr= oboczek <jch@irif.fr> wrote:
Dear all,

This mail is about the consequences of draft-bastian-babel-v4ov6-00 on
ICMPv4 generation.

At last week's meeting, Margaret kindly pointed out that we didn't = do our
homework, and that we didn't consider how ICMPv4 is sent out when the sending router has no IPv4 addresses.=C2=A0 I've looked at a few RFCs, = and here
are my tentative conclusions.

RFC 1812 Section 2.2.7 says:

=C2=A0 =C2=A0In this scheme, a router that
=C2=A0 =C2=A0has unnumbered point to point lines also has a special IP addr= ess,
=C2=A0 =C2=A0called a router-id in this memo.=C2=A0 The router-id is one of= the
=C2=A0 =C2=A0router's IP addresses (a router is required to have at lea= st one IP
=C2=A0 =C2=A0address).=C2=A0 This router-id is used as if it is the IP addr= ess of all
=C2=A0 =C2=A0unnumbered interfaces.

So it looks like it was decided back in 1995 that all IPv4 routers need at<= br> least one IPv4 address.=C2=A0 Much as I tried, I couldn't find anything= that
would relax this requirement.=C2=A0 As expected, when an ICMPv4 packet is s= ent
over an unnumbered interface, the distinguished "router-id" addre= ss is
used as the source address:

=C2=A0 =C2=A0the IP source address in an ICMP message originated by the rou= ter MUST
=C2=A0 =C2=A0be one of the IP addresses associated with the physical interf= ace over
=C2=A0 =C2=A0which the ICMP message is transmitted.=C2=A0 If the interface = has no IP
=C2=A0 =C2=A0addresses associated with it, the router's router-id (see = Section
=C2=A0 =C2=A0[5.2.5]) is used instead.

(This appears to be a typo -- there's nothing relevant in Section 5.2.5= .)

Interestingly, there appears to be nothing in RFC 1812 that specifies that<= br> the router-id is globally unique; thus, what we could do would be to put the same IPv4 address on all routers.=C2=A0 This would make traceroute a li= ttle
confusing (RFC 5837 might help), but it would solve both the problem with ICMPv4 blackholes and compliance with RFC 1812.

In the light of the above, and in the immortal words of Lenin, what shall w= e do?

1. Pick a private IPv4 (say 10.42.42.42) and put it on the loopback
=C2=A0 =C2=A0interface of all unnumbered routers.

2. Request a dedicated IPv4 address (the "all-routers anycast address&= quot;) to
=C2=A0 =C2=A0be used as the loopback address of unnumbered routers.

3. Update RFC 1812 to allow unnumbered routers and 0.0.0.0 as the source =C2=A0 =C2=A0address of ICMPv4 packets.

I'm interested in the comments of wise people.

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--0000000000002d7e6205abee8ecd-- From nobody Sun Aug 2 18:18:34 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3625E3A0796 for ; Sun, 2 Aug 2020 18:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLsOA_4-J3yz for ; Sun, 2 Aug 2020 18:18:31 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 73D663A0772 for ; Sun, 2 Aug 2020 18:18:31 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id g19so24892312ioh.8 for ; Sun, 02 Aug 2020 18:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4kZUBDyayraThWSALmZhpNKm+GvtGKO1vQMoQbZ27gU=; b=R0vjvTwo4bpTfmkRp5UzBvrAowdtCvK63jPxkw41j/IqHyKmQdIJCvgTNzVHB5t2Zb +R3b/IvZlYT6rcEcaHigDtzuYKl+1qYGY+Trym04XaxK9N+7xV0y0IuywCoUb2GgYadY ad3F1waEwYaVWTTmKhvIud2rQL4MRn6qurW/E47xR/bGGjF2dYs9+DuTVRlyvRwmr6U9 2EjRwsr3/cGUNvCu6UQJIxXAyE8xwia129BjQYgAvYe8HPbHf9cRqQEkl9lzD6ComIp0 ScOVk+GiwR6TfZiCfdDbCkLL9jaox3oOEvFLrke+IPFR8u3ZWApcY+XSYwKTAfwZXleJ Bufw== 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=4kZUBDyayraThWSALmZhpNKm+GvtGKO1vQMoQbZ27gU=; b=eKJg7mcqpeH2psjLJmK87I/kwwqxERdKRbT3OcGGGwEzC6J07pgQTou3ASsMXu9oIJ /POsWcrz4rGqSKIOQX0BrJAc2MzWXvb+TgGpiNu6ANSFk5NAmtNpNz4Ek0477prC4sck MU7CEYAogB0GqOWCgAYVPm/smuX/MXgy4hbov8E9G57aibv1mDFdnZDLkWLJYUy5a4s7 NlMeGXO93u7YQg4y1t0BLXNC802zdaL1/q616ZPWDksa4YOHDviAhg0jdEy+AsDDciCR Ms2mclFxEUn2aASg23ILR2pmT6FBS/RQDdJBcnrj8h0evGYsztGUV+Y2oT7Bk77WJ8nl /9vA== X-Gm-Message-State: AOAM533Gkf7D09PHZoC7Tv3XuI+QOduxq/XloJyKBAMOE8aBybEzpGjL Z/+mcx2tg2k7zUEU4hpZTPCzHJc+/BxacX9QX8s= X-Google-Smtp-Source: ABdhPJyktHchhxrlrfes++v3zXmfzsNLu7XSsMn7HUqkqPYY70Lo+04JcuIsnud/vnjolsDH3HvLT/v8sKAqi/aZ0No= X-Received: by 2002:a5e:db0d:: with SMTP id q13mr14059691iop.87.1596417510489; Sun, 02 Aug 2020 18:18:30 -0700 (PDT) MIME-Version: 1.0 References: <87pn88kgs0.wl-jch@irif.fr> In-Reply-To: <87pn88kgs0.wl-jch@irif.fr> From: Donald Eastlake Date: Sun, 2 Aug 2020 21:18:19 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , Margaret , =?UTF-8?Q?Th=C3=A9ophile_Bastian?= Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] About ICMP and unnumbered routers X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 03 Aug 2020 01:18:33 -0000 Hi Juliusz/David, Thanks for the research. See below. On Sun, Aug 2, 2020 at 3:08 PM Juliusz Chroboczek wrote: > Dear all, > > This mail is about the consequences of draft-bastian-babel-v4ov6-00 on > ICMPv4 generation. > > At last week's meeting, Margaret kindly pointed out that we didn't do our > homework, and that we didn't consider how ICMPv4 is sent out when the > sending router has no IPv4 addresses. I've looked at a few RFCs, and here > are my tentative conclusions. > > RFC 1812 Section 2.2.7 says: > > In this scheme, a router that > has unnumbered point to point lines also has a special IP address, > called a router-id in this memo. The router-id is one of the > router's IP addresses (a router is required to have at least one IP > address). This router-id is used as if it is the IP address of all > unnumbered interfaces. > > So it looks like it was decided back in 1995 that all IPv4 routers need at > least one IPv4 address. Much as I tried, I couldn't find anything that > would relax this requirement. As expected, when an ICMPv4 packet is sent > over an unnumbered interface, the distinguished "router-id" address is > used as the source address: > > the IP source address in an ICMP message originated by the router MUST > be one of the IP addresses associated with the physical interface over > which the ICMP message is transmitted. If the interface has no IP > addresses associated with it, the router's router-id (see Section > [5.2.5]) is used instead. > > (This appears to be a typo -- there's nothing relevant in Section 5.2.5.) > > Interestingly, there appears to be nothing in RFC 1812 that specifies that > the router-id is globally unique; thus, what we could do would be to put > the same IPv4 address on all routers. This would make traceroute a little > confusing (RFC 5837 might help), but it would solve both the problem with > ICMPv4 blackholes and compliance with RFC 1812. > > In the light of the above, and in the immortal words of Lenin, what shall we do? > 1. Pick a private IPv4 (say 10.42.42.42) and put it on the loopback > interface of all unnumbered routers. I would recommend against this due to possible collisions. > 2. Request a dedicated IPv4 address (the "all-routers anycast address") to > be used as the loopback address of unnumbered routers. I think this is the best way forward. Probably the "IPv4 dummy address" David Schinazi found would do fine. (If there is any problem with that, getting a new special use IPv4 address for this purpose would be pretty easy. The assignment requirement is "IETF Review" which means any document that goes through IETF Last call will do as the basis for a new assignment. https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml) > 3. Update RFC 1812 to allow unnumbered routers and 0.0.0.0 as the source > address of ICMPv4 packets. Updating RFC 1812 seems like a more difficult path and possibly there are routers or middle boxes that discard packets with a 0.0.0.0 source as bogus. I don't know if the text is still valid but RFC 1122 says of 0.0.0.0 source: This host on this network. MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its own IP address. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > I'm interested in the comments of wise people. > > -- Juliusz From nobody Sun Aug 2 22:22:46 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2653A0AEA; Sun, 2 Aug 2020 22:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3PAylNw-imc; Sun, 2 Aug 2020 22:22:43 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 9AA523A0AF5; Sun, 2 Aug 2020 22:22:43 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id t18so30132076ilh.2; Sun, 02 Aug 2020 22:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H2b7hpDn3w6YiO0yv7K2LyKfOyTIwU+QWWSR+Hq5a0s=; b=PFYU3x7cWhzLm51qt94X9K1Fri5y+iAgTeVgXMXpBccOQLMAM5IB5U2WqleGv6jOOZ t42Q4O+SpPSnkCbN61A5HwqcCQV4k2j0KNotaRWL53Ysek11C0Iy2PV4/vDwQKwOKti1 nGYp0BJeQJN+oZDh18JEwD0PUzcbjIBoQJf8PnJilmZ6mRjl+ZjFcCQ24wSWiGLA92nE l4zJO7H+vEYQa0VebOwSTd44A+WPOS9oGQvV6yNOGc+BnBHUCwn4TDZJv1xr/ttn/QuO hcP6rLI0/wYHxPwB/i7VLhx5V5BFurO6gNSU29MexKpgxRcjNa9vgg++bTitBSOLy4qq mvWg== 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=H2b7hpDn3w6YiO0yv7K2LyKfOyTIwU+QWWSR+Hq5a0s=; b=unegPz5b9sbGoNaOW45mcwlnXwHu9NtiIGwr5VtFWYf0jhW4GdML+zMztHm27FPU1O A8TxlUGipCm1jsMHzvsjA3iHxaexLDVC5EK0LHaLlW5cg7GfkZ3Wdls0GLoShUvxTG2c bPlLReLuuPpoWYVgJPaAp/tNceHh/YDa1mlSJ26e+x/Lg0MtzUgTetjfebzUL67ayPVJ WBzw3Cy8jsKF5D6Te8a+/xEig8QmLFaqlNB+l3gRDDghEFxNxo1lMp1LAz+fBZds38A9 WcnQSDgf4THrFJNokmoYR9E8eVX8RPOUv4RNan1PUdIrcHGCt0sQw3j1TBPo6niOr1sD ssfA== X-Gm-Message-State: AOAM533k2oabR+yqQMcFH7yCdCDj7MSWh+MXod7PwGStYVwUDgKtdcpk TQOKnjFnkDVedCNmU6jcP7EG9CIaJbm5Ikd9D7A= X-Google-Smtp-Source: ABdhPJw4QUhUUO+ThuCIq0eQ2EN6MnZf/8Z43AmcGbG+Ai2ihoYAeJGCthhIe0ISJLMqUjj77OzYtSBaStXIymsCh7I= X-Received: by 2002:a92:4a0d:: with SMTP id m13mr15343860ilf.276.1596432162763; Sun, 02 Aug 2020 22:22:42 -0700 (PDT) MIME-Version: 1.0 References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <875zn685ne.wl-jch@irif.fr> In-Reply-To: From: Donald Eastlake Date: Mon, 3 Aug 2020 01:22:31 -0400 Message-ID: To: Alvaro Retana Cc: babel-chairs , The IESG , draft-ietf-babel-rfc6126bis@ietf.org, Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 05:22:45 -0000 Hi Alvaro, Please look at version -18 just posted and the diff between it and version -17. I believe that -18 answers the points in your DISCUSS. If so, please clear. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com From nobody Mon Aug 3 08:47:42 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B143A0CBC for ; Mon, 3 Aug 2020 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnFbmTO2mzO8 for ; Mon, 3 Aug 2020 08:47:38 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574673A0CBB for ; Mon, 3 Aug 2020 08:47:38 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 073FhA4T045153; Mon, 3 Aug 2020 11:47:33 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 32pnfa02tv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 11:47:33 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 073FlWMj019235; Mon, 3 Aug 2020 11:47:33 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 073FlRg0019086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Aug 2020 11:47:27 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 5B97D40006BE; Mon, 3 Aug 2020 15:47:27 +0000 (GMT) Received: from GAALPA1MSGEX1CE.ITServices.sbc.com (unknown [135.50.89.112]) by zlp30486.vci.att.com (Service) with ESMTPS id 3B1E74009E62; Mon, 3 Aug 2020 15:47:27 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CE.ITServices.sbc.com (135.50.89.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 3 Aug 2020 11:47:26 -0400 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.004; Mon, 3 Aug 2020 11:47:26 -0400 From: "STARK, BARBARA H" To: "'Donald Eastlake'" , "'Juliusz Chroboczek'" CC: "'Margaret'" , "'Babel at IETF'" , =?iso-8859-1?Q?=27Th=E9ophile_Bastian=27?= Thread-Topic: [babel] About ICMP and unnumbered routers Thread-Index: AQHWaQBJNnzZ1FL2Xk+wcpJTQt99MKkl2P6AgACur6A= Date: Mon, 3 Aug 2020 15:47:26 +0000 Message-ID: <53db6ea1f66a40f5936106357157e25d@att.com> References: <87pn88kgs0.wl-jch@irif.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.105.245] x-tm-snts-smtp: 970F40D2F77E86F502B62F007EEB629097A014023DC290D27532F070E336100E2 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:6.0.235, 18.0.687 definitions=2020-08-03_14:2020-08-03, 2020-08-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=999 spamscore=0 bulkscore=0 clxscore=1011 suspectscore=0 impostorscore=0 mlxscore=0 priorityscore=1501 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008030116 Archived-At: Subject: Re: [babel] About ICMP and unnumbered routers X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 03 Aug 2020 15:47:40 -0000 Has an RFC 5735 169.254.0.0/16 IPv4 link local address been considered? Do = the ICMP packets need to cross routed boundaries? [Sorry, I haven't been pa= ying careful attention to the issue, so I haven't taken the time to underst= and it.] Barbara > -----Original Message----- > From: Donald Eastlake >=20 > Hi Juliusz/David, >=20 > Thanks for the research. See below. >=20 > On Sun, Aug 2, 2020 at 3:08 PM Juliusz Chroboczek wrote: > > Dear all, > > > > This mail is about the consequences of draft-bastian-babel-v4ov6-00 on > > ICMPv4 generation. > > > > At last week's meeting, Margaret kindly pointed out that we didn't do o= ur > > homework, and that we didn't consider how ICMPv4 is sent out when the > > sending router has no IPv4 addresses. I've looked at a few RFCs, and h= ere > > are my tentative conclusions. > > > > RFC 1812 Section 2.2.7 says: > > > > In this scheme, a router that > > has unnumbered point to point lines also has a special IP address, > > called a router-id in this memo. The router-id is one of the > > router's IP addresses (a router is required to have at least one IP > > address). This router-id is used as if it is the IP address of all > > unnumbered interfaces. > > > > So it looks like it was decided back in 1995 that all IPv4 routers need= at > > least one IPv4 address. Much as I tried, I couldn't find anything that > > would relax this requirement. As expected, when an ICMPv4 packet is se= nt > > over an unnumbered interface, the distinguished "router-id" address is > > used as the source address: > > > > the IP source address in an ICMP message originated by the router MU= ST > > be one of the IP addresses associated with the physical interface ov= er > > which the ICMP message is transmitted. If the interface has no IP > > addresses associated with it, the router's router-id (see Section > > [5.2.5]) is used instead. > > > > (This appears to be a typo -- there's nothing relevant in Section 5.2.5= .) > > > > Interestingly, there appears to be nothing in RFC 1812 that specifies t= hat > > the router-id is globally unique; thus, what we could do would be to pu= t > > the same IPv4 address on all routers. This would make traceroute a lit= tle > > confusing (RFC 5837 might help), but it would solve both the problem wi= th > > ICMPv4 blackholes and compliance with RFC 1812. > > > > In the light of the above, and in the immortal words of Lenin, what sha= ll we > do? >=20 > > 1. Pick a private IPv4 (say 10.42.42.42) and put it on the loopback > > interface of all unnumbered routers. >=20 > I would recommend against this due to possible collisions. >=20 > > 2. Request a dedicated IPv4 address (the "all-routers anycast address")= to > > be used as the loopback address of unnumbered routers. >=20 > I think this is the best way forward. Probably the "IPv4 dummy > address" David Schinazi found would do fine. (If there is any problem > with that, getting a new special use IPv4 address for this purpose > would be pretty easy. The assignment requirement is "IETF Review" > which means any document that goes through IETF Last call will do as > the basis for a new assignment. > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.iana.org_assignments_iana-2Dipv4-2Dspecial-2Dregistry_iana- > 2Dipv4-2Dspecial-2Dregistry.xhtml&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3D3AJm3dEuSiQGZ- > ZV79-GC1BPS_4jpUF5cvaTIlD5ZgI&s=3Db0I9NcTMzHIVkI9EZQ5GEcPBe-dg- > xPXFNH5MtgyCH8&e=3D ) >=20 > > 3. Update RFC 1812 to allow unnumbered routers and 0.0.0.0 as the sourc= e > > address of ICMPv4 packets. >=20 > Updating RFC 1812 seems like a more difficult path and possibly there > are routers or middle boxes that discard packets with a 0.0.0.0 source > as bogus. I don't know if the text is still valid but RFC 1122 says of > 0.0.0.0 source: >=20 > This host on this network. MUST NOT be sent, except as > a source address as part of an initialization procedure > by which the host learns its own IP address. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com >=20 > > I'm interested in the comments of wise people. > > > > -- Juliusz >=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=3D3AJm3dEuSiQGZ- > ZV79- > GC1BPS_4jpUF5cvaTIlD5ZgI&s=3D5Nh_1kZZZtr2sloYG14thQ3TVcrnB_0udm7dQ > LdKRfg&e=3D From nobody Mon Aug 3 08:49:15 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7EA3A0CC3 for ; Mon, 3 Aug 2020 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp0HgZBCkh-L for ; Mon, 3 Aug 2020 08:49:12 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107233A0D23 for ; Mon, 3 Aug 2020 08:49:07 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 073FVmq7035056; Mon, 3 Aug 2020 11:49:02 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 32pmqv9efu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Aug 2020 11:49:02 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 073Fn0AR022108; Mon, 3 Aug 2020 11:49:01 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 073Fmt6N021949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Aug 2020 11:48:55 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id A70FB400AE36; Mon, 3 Aug 2020 15:48:55 +0000 (GMT) Received: from GAALPA1MSGEX1CF.ITServices.sbc.com (unknown [135.50.89.113]) by zlp30488.vci.att.com (Service) with ESMTPS id 89F6D400AE35; Mon, 3 Aug 2020 15:48:55 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CF.ITServices.sbc.com (135.50.89.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 3 Aug 2020 11:48:54 -0400 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.004; Mon, 3 Aug 2020 11:48:54 -0400 From: "STARK, BARBARA H" To: "'Donald Eastlake'" , "'Juliusz Chroboczek'" CC: "'Margaret'" , "'Babel at IETF'" , =?iso-8859-1?Q?=27Th=E9ophile_Bastian=27?= Thread-Topic: [babel] About ICMP and unnumbered routers Thread-Index: AQHWaQBJNnzZ1FL2Xk+wcpJTQt99MKkl2P6AgACur6CAAAFA8A== Date: Mon, 3 Aug 2020 15:48:54 +0000 Message-ID: <1fee10554163489db9c736baf8187912@att.com> References: <87pn88kgs0.wl-jch@irif.fr> <53db6ea1f66a40f5936106357157e25d@att.com> In-Reply-To: <53db6ea1f66a40f5936106357157e25d@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.105.245] x-tm-snts-smtp: 36A8217EFD6B3828011C6962C6DDCEC085C0F5E551DA0C35393A18BFB7406C522 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:6.0.235, 18.0.687 definitions=2020-08-03_14:2020-08-03, 2020-08-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 malwarescore=0 spamscore=0 priorityscore=1501 mlxlogscore=999 clxscore=1015 impostorscore=0 bulkscore=0 suspectscore=0 adultscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008030116 Archived-At: Subject: Re: [babel] About ICMP and unnumbered routers X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 03 Aug 2020 15:49:14 -0000 I should have said RFC 3927 169.254.0.0/16 IPv4 link local address. https://tools.ietf.org/html/rfc3927 Barbara > -----Original Message----- > From: STARK, BARBARA H >=20 > Has an RFC 5735 169.254.0.0/16 IPv4 link local address been considered? D= o > the ICMP packets need to cross routed boundaries? [Sorry, I haven't been > paying careful attention to the issue, so I haven't taken the time to > understand it.] > Barbara >=20 > > -----Original Message----- > > From: Donald Eastlake > > > > Hi Juliusz/David, > > > > Thanks for the research. See below. > > > > On Sun, Aug 2, 2020 at 3:08 PM Juliusz Chroboczek wrote: > > > Dear all, > > > > > > This mail is about the consequences of draft-bastian-babel-v4ov6-00 o= n > > > ICMPv4 generation. > > > > > > At last week's meeting, Margaret kindly pointed out that we didn't do= our > > > homework, and that we didn't consider how ICMPv4 is sent out when the > > > sending router has no IPv4 addresses. I've looked at a few RFCs, and > here > > > are my tentative conclusions. > > > > > > RFC 1812 Section 2.2.7 says: > > > > > > In this scheme, a router that > > > has unnumbered point to point lines also has a special IP address, > > > called a router-id in this memo. The router-id is one of the > > > router's IP addresses (a router is required to have at least one I= P > > > address). This router-id is used as if it is the IP address of al= l > > > unnumbered interfaces. > > > > > > So it looks like it was decided back in 1995 that all IPv4 routers ne= ed at > > > least one IPv4 address. Much as I tried, I couldn't find anything th= at > > > would relax this requirement. As expected, when an ICMPv4 packet is > sent > > > over an unnumbered interface, the distinguished "router-id" address i= s > > > used as the source address: > > > > > > the IP source address in an ICMP message originated by the router > MUST > > > be one of the IP addresses associated with the physical interface = over > > > which the ICMP message is transmitted. If the interface has no IP > > > addresses associated with it, the router's router-id (see Section > > > [5.2.5]) is used instead. > > > > > > (This appears to be a typo -- there's nothing relevant in Section 5.2= .5.) > > > > > > Interestingly, there appears to be nothing in RFC 1812 that specifies= that > > > the router-id is globally unique; thus, what we could do would be to = put > > > the same IPv4 address on all routers. This would make traceroute a l= ittle > > > confusing (RFC 5837 might help), but it would solve both the problem > with > > > ICMPv4 blackholes and compliance with RFC 1812. > > > > > > In the light of the above, and in the immortal words of Lenin, what s= hall > we > > do? > > > > > 1. Pick a private IPv4 (say 10.42.42.42) and put it on the loopback > > > interface of all unnumbered routers. > > > > I would recommend against this due to possible collisions. > > > > > 2. Request a dedicated IPv4 address (the "all-routers anycast address= ") to > > > be used as the loopback address of unnumbered routers. > > > > I think this is the best way forward. Probably the "IPv4 dummy > > address" David Schinazi found would do fine. (If there is any problem > > with that, getting a new special use IPv4 address for this purpose > > would be pretty easy. The assignment requirement is "IETF Review" > > which means any document that goes through IETF Last call will do as > > the basis for a new assignment. > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.iana.org_assignments_iana-2Dipv4-2Dspecial-2Dregistry_iana- > > 2Dipv4-2Dspecial-2Dregistry.xhtml&d=3DDwICAg&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3D3AJm3dEuSiQGZ- > > ZV79-GC1BPS_4jpUF5cvaTIlD5ZgI&s=3Db0I9NcTMzHIVkI9EZQ5GEcPBe-dg- > > xPXFNH5MtgyCH8&e=3D ) > > > > > 3. Update RFC 1812 to allow unnumbered routers and 0.0.0.0 as the > source > > > address of ICMPv4 packets. > > > > Updating RFC 1812 seems like a more difficult path and possibly there > > are routers or middle boxes that discard packets with a 0.0.0.0 source > > as bogus. I don't know if the text is still valid but RFC 1122 says of > > 0.0.0.0 source: > > > > This host on this network. MUST NOT be sent, except a= s > > a source address as part of an initialization procedur= e > > by which the host learns its own IP address. > > > > Thanks, > > Donald > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > d3e3e3@gmail.com > > > > > I'm interested in the comments of wise people. > > > > > > -- Juliusz > > > > _______________________________________________ > > 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=3D3AJm3dEuSiQGZ- > > ZV79- > > > GC1BPS_4jpUF5cvaTIlD5ZgI&s=3D5Nh_1kZZZtr2sloYG14thQ3TVcrnB_0udm7dQ > > LdKRfg&e=3D >=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=3DtiGmpKDzY_- > H72AiAJGyH7KnqmLvnnUW_qRpVWtlUh0&s=3DGkxQbxLD8cUTqaegZPMJkByiF > wjB9SDwCM7S3sBuIgQ&e=3D From nobody Mon Aug 3 09:26:27 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF1D3A0F33 for ; Mon, 3 Aug 2020 09:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSCu7GBcI1xg for ; Mon, 3 Aug 2020 09:26:24 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6643A0C99 for ; Mon, 3 Aug 2020 09:26:24 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 073GQIfg017406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Aug 2020 18:26:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 073GQITX026783; Mon, 3 Aug 2020 18:26:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9838DBF706; Mon, 3 Aug 2020 18:26:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9piCXsBB3Lqi; Mon, 3 Aug 2020 18:26:17 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D49B5BF6F7; Mon, 3 Aug 2020 18:26:14 +0200 (CEST) Date: Mon, 03 Aug 2020 18:26:14 +0200 Message-ID: <87h7tjk861.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Babel at IETF'" In-Reply-To: <53db6ea1f66a40f5936106357157e25d@att.com> References: <87pn88kgs0.wl-jch@irif.fr> <53db6ea1f66a40f5936106357157e25d@att.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 03 Aug 2020 18:26:19 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 03 Aug 2020 18:26:18 +0200 (CEST) X-Miltered: at korolev with ID 5F283AAA.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F283AAA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F283AAA.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F283AAA.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 : 5F283AAA.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F283AAA.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] About ICMP and unnumbered routers X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 03 Aug 2020 16:26:27 -0000 > Has an RFC 5735 169.254.0.0/16 IPv4 link local address been considered? > Do the ICMP packets need to cross routed boundaries? Yes. If there's an MTU mismatch and a packet has the DF bit set, then the router needs to send back a Packet Too Big message to the originator, else a blackhole will occur (except if RFC 4821 is implemented, but even if it is, PTB packets make convergence faster). Note howver, that I'm not sure whether routers block packets with 169.254/16 in the *source* address (as opposed to the destination). -- Juliusz From nobody Wed Aug 5 07:38:05 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03F3A0A4D for ; Wed, 5 Aug 2020 07:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-t5PAZU9Kv8 for ; Wed, 5 Aug 2020 07:38:01 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132033A0A2E for ; Wed, 5 Aug 2020 07:38:00 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id z3so27326453ilh.3 for ; Wed, 05 Aug 2020 07:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mPcbMQ3LPSlx3tVyxX+mZQLKLLM4kWARhbBqLWuwItg=; b=igx2WpQwV2CfAH6hElUb/nnjTx40oFZFvuw1LkxEjrJuAfOcQBMYKF43WEfhHSa3Kq ZYFT/3gVRqVw3/O8E62vDcri/mdkBvw8TQpoA7PbnMoystb68Nf3oupKicerOjIdP9qb V22JuGXwJ/rIO+BAAUJ24FYiEu3w3fZ3PfeNMdx0+O4J3DCjz7IDlmBGw5Htj/2FBd2e vL8TxZ/PYz1X9iA1B1lt7kx1xvOlmldgaA88UK49UH8lgFyMd0EZjBOxOWrj8rFEYhoF FwWzSAEJDk2YTSgD5L0wonuwtqmy9Ct4yHgYvuISu/vby4cyfzPyD4tCJT1uCVoA9Njx cicA== 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; bh=mPcbMQ3LPSlx3tVyxX+mZQLKLLM4kWARhbBqLWuwItg=; b=St+SbQ2/Txb3mMwYY5COukqdl83IJqQW0jgw5gyYzf2XlmxaDUyiVSUDrc/wNMzTJK ctbEyDTFWnGg/BBiiMP6Pf+Kll4Bo3TGg+WwftggNFiiZCNwV46MDEUT7fjnA4XnNpMt h9sluXS4MbN95wnd4884Sr+oEfOvSdCsvX1EFF0+TviptGBtfTFqKFr3xaRTC/Ruvqgl fZlh5TadYCHqQRnkHjEEWrFwX00c/dv24dl8ufJ0zsrlLET8Bn4p6YNClByRGwT7792b mxZYsqRBU5xOm1sJFPG6KhNeO6T3LFHeWg6AQdvza2sUADP0VdpAL0BmIKbJBlkHXDon qbQw== X-Gm-Message-State: AOAM533+6LNympEaYYnHIOXSNdDfE0GID9pGr0qKbSAuJIqvNZOLuDtO u1rFtWbEJa8ul8k05NTQRQ1iUJEGCzXOyzK6/TyPrg== X-Google-Smtp-Source: ABdhPJy982iU9X9AZzAu5/FFOL0sgqSNxyOd8J5ulvVMmm3IMga4dGSpM+qxHrCkboXFrsBtsKnGEI4HcC8UTyJ72ng= X-Received: by 2002:a05:6e02:f07:: with SMTP id x7mr4533166ilj.40.1596638278860; Wed, 05 Aug 2020 07:37:58 -0700 (PDT) MIME-Version: 1.0 References: <8736adzf78.wl-jch@irif.fr> <910042DE-5141-487D-9A04-6701E4F36296@iki.fi> <87tv2rdpkg.wl-jch@irif.fr> In-Reply-To: From: Donald Eastlake Date: Wed, 5 Aug 2020 10:37:47 -0400 Message-ID: To: Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] No experimental range in the AE registry X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:38:03 -0000 Hi, There were no objections to changing the IANA Considerations for AE values to include an Experimental range as discussed a while ago. We have consulted with the Area Director for Babel and we plan to go ahead and make this change along with designating the value 255 as "Reserved". Because of the turnover in IESG members, it is also planned to schedule the draft for another IESG telechat to get more Area Director positions on the draft. So you will probably see some Comments or the like from them come by in a while. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Sat, Mar 14, 2020 at 12:45 PM Donald Eastlake wrote: > > Hi Juliusz, > > On Sat, Mar 14, 2020 at 9:38 AM Juliusz Chroboczek wrote: > > > > Hi Donald, > > > > > We could have use the early allocation procedures in RFC 7120 to allocate AE > > > codepoints except that rfc6126bis does not set up an IANA registry to those > > > codepoints. > > > > Yes it does. Please see Section 5 of rfc6126bis: > > > > IANA is instructed to create a registry called "Babel Address > > Encodings". The allocation policy for this registry is Specification > > Required. The values in this registry are as follows: > > > > +----+-------------------------+---------------+ > > | AE | Name | Reference | > > +----+-------------------------+---------------+ > > | 0 | Wildcard address | this document | > > | | | | > > | 1 | IPv4 address | this document | > > | | | | > > | 2 | IPv6 address | this document | > > | | | | > > | 3 | Link-local IPv6 address | this document | > > +----+-------------------------+---------------+ > > Sorry, I was confused. The rfc6126bis draft takes effect on being move > to the RFC Editor by the managing AD, Martin Vigoureux in this case, > which certifies that it has been approved by the IESG. At that point, > the AE registry would be added to the IANA Babel web page. > > > What we're suggesting is to add the following entries to that table: > > > > 4-223 -- Unassigned > > 224-254 -- Reserved for Experimental Use > > 255 -- Unassigned > > So, looking t the proposed AE registry in rfc6126bis, I'm surprised it > got through without some reviewer at some level (I missed this also) > complaining that it has no explicit "reserved" value (should probably > be 255) and didn't have a "4-255 unassigned" line although adding such > an unassigned line is the sort of thing commonly done by IANA and the > RFC Editor after draft approval as it is implied by the draft anyway. > > > What I'm asking is -- should we do it now, in the next revision of the > > draft, or should we merely establish WG consensus now, with a view to > > amending the IANA registry after the RFC is published. > > I think that as this point we should not make changes in rfc6126bis > that are not needed to get it through the IESG. Just put the revised > registry in the Babel IPv4 over IPv6 draft and for now just use AE=4 > if an AE value is needed > > Note that, since the AE value assignment criteria is Specification > Required, if rfc6126bis were through the IESG and the IANA Babel AE > registry existed, then as soon as there was a complete Babel IPv4 over > IPv6 draft, even a personal draft before WG adoption, an AE value > could be assigned based on that IPv4 over IPv6 draft as the > specification. (There is a slight complication that an expert > determination that the specification is adequate for interoperability > is needed for Specification Required which might cause a little > delay.) > > > -- Juliusz > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 33896 USA > d3e3e3@gmail.com From nobody Thu Aug 6 17:29:19 2020 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 19A6B3A0ADD; Thu, 6 Aug 2020 17:29:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <159676015801.17184.1333296584357491779@ietfa.amsl.com> Date: Thu, 06 Aug 2020 17:29:18 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-19.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 00:29:18 -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-19.txt Pages : 70 Date : 2020-08-06 Abstract: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-19 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 7 13:27:12 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C8F3A0992; Fri, 7 Aug 2020 13:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRW_HCivU4a2; Fri, 7 Aug 2020 13:27:09 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 4AF503A098B; Fri, 7 Aug 2020 13:27:09 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id l17so3162627iok.7; Fri, 07 Aug 2020 13:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x/fG3cOUt2ymZbowOwFzsiXENX3wjb9IuGfSOGer/rs=; b=gXslvtupnKUf2QdWr5+7rP4GgJMEuK4dRKa2XBW0LJUQPKPVEgrOyePdiOkSqGn9HL 9KshVsroqeZXPzySCKvsH2M1qcj1AKN0iiBcer+xa8vVmNLef9VxTvrWCO6H0LwnnzTQ bv7KBmiixMkjz/s3n1sh9RVtQrkggk/Efy11Dh6tIOf5BEsnukiF5P54x3WuKSd9ctzU ns2zlTKw6k+nDZKBp6eFE4zrim9DEwUR3KI2TGtiK812uzyUwY2Tlv76PBi4Y2Z37s+J ySNCxV3qUhP2FfakYLBqSQvAL6Q7mfqAfjVRPTwS1zg422Lfibc6LdUgIWY7AkwBKK6x SlSg== 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=x/fG3cOUt2ymZbowOwFzsiXENX3wjb9IuGfSOGer/rs=; b=icDTH94hE92B7NquSVIcms+vM+HQfyFlQeD34EBRO0MrFtfiNYQCKMIrUzSfDibSTS cqQEOBllGdIa7iZKVwMdPUfe16gaHa3QjjrwO08QBEQ0+uuin6izp9zss7GklD/D87Iu zM/n/AZLVYRcXPvow6o0IoJk2NwyAkcPq0/MJDQ0V6CCEjWXI+oQVYqM9kfrA7hgg5g4 t/gIFPK3+mVNnQgwNtNctJtdqqKZTcM16O91RiYW22/TTVmwGDMZeSz+fGCn+7xmwfCl 6SpPNWJJ0dBMjtzFdSzYsPRhOExdFN5ET0enyoHzMVfm5xOl72Ehf+bUD+gfTwnO6GeH 01gg== X-Gm-Message-State: AOAM531sND6suBQ6UqQT1GQQcr94wxt2j/y0plZ+dJRXe5LZYk+aRYNh /j+Hc5ao8AD4BllXXHxjuot7dqJlQGEoRZcdINKsgw== X-Google-Smtp-Source: ABdhPJyQvdNDqEKSIM/UPu6Gs+7p+BDXLo273fdXv6D+6ohwFr1wvKOwNFq9v4nKcq+ClI0JdB0FkTqkIGwwS72fucI= X-Received: by 2002:a6b:b513:: with SMTP id e19mr6080314iof.167.1596832027827; Fri, 07 Aug 2020 13:27:07 -0700 (PDT) MIME-Version: 1.0 References: <159676015801.17184.1333296584357491779@ietfa.amsl.com> In-Reply-To: <159676015801.17184.1333296584357491779@ietfa.amsl.com> From: Donald Eastlake Date: Fri, 7 Aug 2020 16:26:56 -0400 Message-ID: To: Babel at IETF Cc: i-d-announce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-rfc6126bis-19.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 20:27:11 -0000 This revision implements the change to IANA Considerations for AE values that has been discussed on this mailing list. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Thu, Aug 6, 2020 at 8:29 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Babel routing protocol WG of the IETF. > > Title : The Babel Routing Protocol > Authors : Juliusz Chroboczek > David Schinazi > Filename : draft-ietf-babel-rfc6126bis-19.txt > Pages : 70 > Date : 2020-08-06 > > Abstract: > Babel is a loop-avoiding distance-vector routing protocol that is > robust and efficient both in ordinary wired networks and in wireless > mesh networks. This document describes the Babel routing protocol, > and obsoletes RFCs 6126 and 7557. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-19 > https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-19 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-19 > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From nobody Fri Aug 14 20:34:32 2020 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 688A53A155B; Fri, 14 Aug 2020 20:34:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <159746246737.19251.15275813572859669820@ietfa.amsl.com> Date: Fri, 14 Aug 2020 20:34:27 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-information-model-11.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 03:34:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Information Model Authors : Barbara Stark Mahesh Jethanandani Filename : draft-ietf-babel-information-model-11.txt Pages : 21 Date : 2020-08-14 Abstract: This Babel Information Model provides structured data elements for a Babel implementation reporting its current state and may allow limited configuration of some such data elements. This information model can be used as a basis for creating data models under various data modeling regimes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-information-model-11 https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 14 20:52:31 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347513A1549 for ; Fri, 14 Aug 2020 20:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_uuK3AjP0nR for ; Fri, 14 Aug 2020 20:52:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF91A3A1548 for ; Fri, 14 Aug 2020 20:52:28 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 07F3XJv3041447 for ; Fri, 14 Aug 2020 23:52:27 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 32x3tg3717-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 14 Aug 2020 23:52:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 07F3qQUH004988 for ; Fri, 14 Aug 2020 23:52:26 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 07F3qMK2004958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Aug 2020 23:52:22 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id A25FE400B579 for ; Sat, 15 Aug 2020 03:52:22 +0000 (GMT) Received: from GAALPA1MSGEX1CF.ITServices.sbc.com (unknown [135.50.89.113]) by zlp30485.vci.att.com (Service) with ESMTPS id 8C976400B575 for ; Sat, 15 Aug 2020 03:52:22 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CF.ITServices.sbc.com (135.50.89.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Fri, 14 Aug 2020 23:52:10 -0400 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.004; Fri, 14 Aug 2020 23:52:10 -0400 From: "STARK, BARBARA H" To: "babel@ietf.org" Thread-Topic: [babel] I-D Action: draft-ietf-babel-information-model-11.txt Thread-Index: AQHWcrUBdWsh8Y8N8Uy7g1w6wMvgkqk4iJ+Q Date: Sat, 15 Aug 2020 03:52:10 +0000 Message-ID: <33027937cafe428ca98aa8f5ed342c37@att.com> References: <159746246737.19251.15275813572859669820@ietfa.amsl.com> In-Reply-To: <159746246737.19251.15275813572859669820@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.69.170] x-tm-snts-smtp: 1DB422763FE49430CC6629015570C5392F64A7AFD5807C238B40B0D447B7632B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-15_01:2020-08-14, 2020-08-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_spam policy=outbound_policy score=51 bulkscore=0 mlxscore=51 spamscore=51 suspectscore=0 priorityscore=1501 clxscore=1015 mlxlogscore=-1 lowpriorityscore=0 malwarescore=0 adultscore=0 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008150025 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-11.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 03:52:30 -0000 Hi Babel, The -11 draft I just uploaded includes Antonin's editorial fixes, a sentenc= e added to clarify behavior of babel-stats-reset, and a sentence added to i= mplore implementers to be careful with memory management for babel-packet-l= og. Barbara > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Babel routing protocol WG of the IETF. >=20 > Title : Babel Information Model > Authors : Barbara Stark > Mahesh Jethanandani > Filename : draft-ietf-babel-information-model-11.txt > Pages : 21 > Date : 2020-08-14 >=20 > Abstract: > This Babel Information Model provides structured data elements for a > Babel implementation reporting its current state and may allow > limited configuration of some such data elements. This information > model can be used as a basis for creating data models under various > data modeling regimes. From nobody Sun Aug 16 19:20:31 2020 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 867FA3A1311; Sun, 16 Aug 2020 19:20:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-babel-dtls@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <159763082952.17304.922256301788860509@ietfa.amsl.com> Date: Sun, 16 Aug 2020 19:20:29 -0700 Archived-At: Subject: [babel] Erik Kline's No Objection on draft-ietf-babel-dtls-10: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 02:20:30 -0000 Erik Kline has entered the following ballot position for draft-ietf-babel-dtls-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments ]] [ section 5 ] * The first sentence of the 3rd paragraphs reads to me like "while DTLS provides protection against replay attacks an attacker can still mount a replay attack". I don't have any constructive proposal to change this, but if it tickles something in your mind that might be more clear to those not super knowledgeable about DTLS, I'm sure that'll be great. From nobody Mon Aug 17 01:23:00 2020 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 7F4543A1407; Mon, 17 Aug 2020 01:22:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-babel-hmac@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <159765257449.19289.10819539904603575870@ietfa.amsl.com> Date: Mon, 17 Aug 2020 01:22:54 -0700 Archived-At: Subject: [babel] Erik Kline's No Objection on draft-ietf-babel-hmac-10: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 08:22:55 -0000 Erik Kline has entered the following ballot position for draft-ietf-babel-hmac-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments ]] [ section 4.3 ] * s/worthwile/worthwhile/ [ section 5 ] * Is another option for implementations to be in a mode where: - they send authenticated packets - they attempt to authenticate packets received - if a packet does not authenticate is it still accepted - if a packet does authenticate then the neighbor entry is updated to note that all future communications with that neighbor must be use authentication (and any unauthenticated packets from this neighbor are dropped and maybe logged)? [ section 7 ] * s/an administators/an administrator's/, I think From nobody Mon Aug 17 03:02:15 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941003A1478; Mon, 17 Aug 2020 03:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCbR8VDD0yuU; Mon, 17 Aug 2020 03:02:08 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FFC03A1477; Mon, 17 Aug 2020 03:02:07 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 07HA23IT005990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Aug 2020 12:02:03 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 07HA23dF015553; Mon, 17 Aug 2020 12:02:03 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 88375AAD5F; Mon, 17 Aug 2020 12:02:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id LLsshbqKwML8; Mon, 17 Aug 2020 12:02:02 +0200 (CEST) Received: from pirx.irif.fr (unknown [37.167.70.34]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9DA39AAD5D; Mon, 17 Aug 2020 12:02:00 +0200 (CEST) Date: Mon, 17 Aug 2020 12:01:59 +0200 Message-ID: <877dtx6160.wl-jch@irif.fr> From: Juliusz Chroboczek To: Erik Kline Cc: "The IESG" , draft-ietf-babel-hmac@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake In-Reply-To: <159765257449.19289.10819539904603575870@ietfa.amsl.com> References: <159765257449.19289.10819539904603575870@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 17 Aug 2020 12:02:03 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 17 Aug 2020 12:02:03 +0200 (CEST) X-Miltered: at korolev with ID 5F3A559B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F3A559B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F3A559B.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F3A559B.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 : 5F3A559B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F3A559B.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] Erik Kline's No Objection on draft-ietf-babel-hmac-10: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 10:02:10 -0000 > * s/worthwile/worthwhile/ Done, thanks. > * Is another option for implementations to be in a mode where: [snipped] It's certainly a good idea, but it's not described in this document. First, we haven't implemented it, and as a principle the Babel working group refrains from standardising features that don't have at least one implementation (this has been broken on a few occasions, notably due to the insistence of some IESG members, but it remains a principle we try to stick to). Second, the document tries to accurately describe the security properties that have been proven to hold; I haven't given it a lot of thought, but it could conceivably take some work to formulate the security properties of the subprotocol that you suggest and to prove that they hold. While I don't think the document should be delayed any further, I think it would be a good idea to write up, implement and prove the correctness of the subprotocol that you suggest. Should you wish to do so, I'd be glad to collaborate with you. > * s/an administators/an administrator's/, I think Done, thanks. I'll submit a new revision ASAP. -- Juliusz From nobody Wed Aug 19 00:36:35 2020 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 28BBC3A10E5; Wed, 19 Aug 2020 00:36:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <159782259266.4862.8769299602644465106@ietfa.amsl.com> Date: Wed, 19 Aug 2020 00:36:33 -0700 Archived-At: Subject: [babel] Erik Kline's No Objection on draft-ietf-babel-rfc6126bis-19: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 07:36:33 -0000 Erik Kline has entered the following ballot position for draft-ietf-babel-rfc6126bis-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ general ] * I couldn't find where any of the multi-byte numeric fields have their endianness specified. Consider a blanket "everything's network byte order" somewhere appropriate, or maybe spell it out explicitly in: * section 4.2: Body length * section 4.6.3: Interval * section 4.6.5: Seqno * section 4.6.5: Interval * section 4.6.6: Rxcost * section 4.6.6: Interval * section 4.6.9: Interval * section 4.6.9: Seqno * section 4.6.9: Metric * section 4.6.11: Seqno [ section 3.6 ] * s/this kind of instabilities/these kind of instabilities/, I think [ section 3.8.1.2 ] * Perhaps s/it has finite metric/it has a finite metric/ [ section 4.4 ] * Can a sub-TLV have sub-TLVs of its own? [ section 4.5 ] * s/derived derived/derived/ [ Appendix A.3 ] * s/results ;/results;/ maybe From nobody Wed Aug 19 14:18:22 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6771B3A0B33; Wed, 19 Aug 2020 14:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDPD9j4hFrIM; Wed, 19 Aug 2020 14:18:10 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D393A0BBE; Wed, 19 Aug 2020 14:18:10 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id i19so12816087lfj.8; Wed, 19 Aug 2020 14:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/p/1xHQuSnx6YkE5iBfoBrEH61qjkC73b+GhFRa3o3w=; b=BcGKfdb/qP3j/9O27WJUPfdh5EDOV9qTENDxKioWLd7/cjLB4Jky1ibonu9lqpAVza PzMlKXh9WeNWtkarEZMRqgBTz6JIcWMt3A1rLKq0LRo6ppBzKhiOjEYvNC2d/U4GNHVY 9DGj0p6mFKeMcrvUqNk5rFTbZfkOSHwdzjvkj/EFfo+NQAPjXC1EiJF2hz7gtdgWHxCT G7bUN0y0H0pMifPV0oOTz1/uCQmqtl80PxsO0X3gZAsg+NfquRH6xKaQdliWSNrrHZ51 An7qzImSZNTjle8S5PTujH941431KYvNhcrMLnBTayJZCtc/TT5dhwv6Nd4so9yesEne hU8A== 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=/p/1xHQuSnx6YkE5iBfoBrEH61qjkC73b+GhFRa3o3w=; b=oUCUO7kZEv246Oaw3RbXOIecWmIaoQrxKRLRKAxqCE2Ok9vIvaneuNmsxTTSoXVGw/ BbHanBs8WSO/aZAiWdgF24eyvUmneF72n3RzpjMcjTPb9AxDBL++cyco6spyi80WkA9G R9BSnwd3hSHbxRu00ttNUZAvyHKwl7Nx2LoFLMcrKIlmJPInQ3oQbKT8U/m9mCAXbKm2 3mmFYoX203IK2b+sHjvPWs8gMhAECIgPGE+gglWyU8+GxHLE2BGFsukF8/tNKU/eMLBF 8LbbTq/PwgCKJqZ/eKf+Ku1nNz6LCDdU/TO7OtEIDBEX2uB7KNcwFo2y4eoqs65WhJzv WJWg== X-Gm-Message-State: AOAM530z1/iwQvocE5nK+nM3Oyv+AeSBMNW/GD1iWPoyScV/v5bIget9 SyGUd8szhosTmjhcomfuf4EZKURDVeOxFrierI4= X-Google-Smtp-Source: ABdhPJxK2t5sD0C50+bkdHvIVrVwzKAGBYflYHlKcnzwDiZ+0RNq0qGIkChPbYzYXt0Peu4n+JL9wpYD1TvNC+HJoVM= X-Received: by 2002:ac2:4d16:: with SMTP id r22mr25520lfi.21.1597871888364; Wed, 19 Aug 2020 14:18:08 -0700 (PDT) MIME-Version: 1.0 References: <159782259266.4862.8769299602644465106@ietfa.amsl.com> In-Reply-To: <159782259266.4862.8769299602644465106@ietfa.amsl.com> From: David Schinazi Date: Wed, 19 Aug 2020 14:17:57 -0700 Message-ID: To: Erik Kline Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs , Babel at IETF , Donald Eastlake Content-Type: multipart/alternative; boundary="0000000000004d79e605ad418acb" Archived-At: Subject: Re: [babel] Erik Kline's No Objection on draft-ietf-babel-rfc6126bis-19: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 21:18:13 -0000 --0000000000004d79e605ad418acb Content-Type: text/plain; charset="UTF-8" Thanks for the review Erik! Your comments make sense to me. We'll discuss them amongst the authors and will most likely include them in the next revision of the draft. David On Wed, Aug 19, 2020 at 12:36 AM Erik Kline via Datatracker < noreply@ietf.org> wrote: > Erik Kline has entered the following ballot position for > draft-ietf-babel-rfc6126bis-19: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [ general ] > > * I couldn't find where any of the multi-byte numeric fields have their > endianness specified. Consider a blanket "everything's network byte > order" somewhere appropriate, or maybe spell it out explicitly in: > > * section 4.2: Body length > * section 4.6.3: Interval > * section 4.6.5: Seqno > * section 4.6.5: Interval > * section 4.6.6: Rxcost > * section 4.6.6: Interval > * section 4.6.9: Interval > * section 4.6.9: Seqno > * section 4.6.9: Metric > * section 4.6.11: Seqno > > [ section 3.6 ] > > * s/this kind of instabilities/these kind of instabilities/, I think > > [ section 3.8.1.2 ] > > * Perhaps s/it has finite metric/it has a finite metric/ > > [ section 4.4 ] > > * Can a sub-TLV have sub-TLVs of its own? > > [ section 4.5 ] > > * s/derived derived/derived/ > > [ Appendix A.3 ] > > * s/results ;/results;/ maybe > > > > --0000000000004d79e605ad418acb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review Erik!

Your commen= ts make sense to me. We'll discuss
them amongst the authors a= nd will most likely
include them in the next revision of the draf= t.

David

On Wed, Aug 19, 2020 at 12:36 AM Eri= k Kline via Datatracker <noreply@iet= f.org> wrote:
Erik Kline has entered the following ballot position for
draft-ietf-babel-rfc6126bis-19: No Objection

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


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


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



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

[ general ]

* I couldn't find where any of the multi-byte numeric fields have their=
=C2=A0 endianness specified.=C2=A0 Consider a blanket "everything'= s network byte
=C2=A0 order" somewhere appropriate, or maybe spell it out explicitly = in:

=C2=A0 =C2=A0 * section 4.2:=C2=A0 =C2=A0 Body length
=C2=A0 =C2=A0 * section 4.6.3:=C2=A0 Interval
=C2=A0 =C2=A0 * section 4.6.5:=C2=A0 Seqno
=C2=A0 =C2=A0 * section 4.6.5:=C2=A0 Interval
=C2=A0 =C2=A0 * section 4.6.6:=C2=A0 Rxcost
=C2=A0 =C2=A0 * section 4.6.6:=C2=A0 Interval
=C2=A0 =C2=A0 * section 4.6.9:=C2=A0 Interval
=C2=A0 =C2=A0 * section 4.6.9:=C2=A0 Seqno
=C2=A0 =C2=A0 * section 4.6.9:=C2=A0 Metric
=C2=A0 =C2=A0 * section 4.6.11: Seqno

[ section 3.6 ]

* s/this kind of instabilities/these kind of instabilities/, I think

[ section 3.8.1.2 ]

* Perhaps s/it has finite metric/it has a finite metric/

[ section 4.4 ]

* Can a sub-TLV have sub-TLVs of its own?

[ section 4.5 ]

* s/derived derived/derived/

[ Appendix A.3 ]

* s/results ;/results;/ maybe



--0000000000004d79e605ad418acb-- From nobody Thu Aug 20 03:31:19 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00883A0770 for ; Thu, 20 Aug 2020 03:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WJR2CrtIcPs for ; Thu, 20 Aug 2020 03:31:14 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF963A0317 for ; Thu, 20 Aug 2020 03:31:14 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id k12so1072408otr.1 for ; Thu, 20 Aug 2020 03:31:14 -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=GwVs1JfTQlTL+FeYvRlibmsF2LJbAe6FKsCE1bxwhmE=; b=gvwec+rns3/WqKhYOcmUcOYt+REdMJXkWjitbH94eMN+1Dw584iddHXRRzm6Il9uXK BU1+oJZZOJpRKNKfajJ/DdFFMPZjRd5cE+hCYPodpnHBfbWrRJQs1wB19wqjkIdF+GZt /Rm7FrIqeZNW1hyfKI12BXAJkuan7OjFSNndC4F9BB2RAWx25z0Wq5dUMJnSbhU6Fn0d ifWoRys5jYlq6EixKXdbv/ZgTTBe/E1z7NepE9mhLvT6vaLvrNX4lM0rOyr+Ag4OhuAV x4h5c8M/Lm9hkWKDktZWyOAAk+vUsHoGBm350GKdpCT/C+aMi5zNO9MAH39w1gNHrOOY ygkA== 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=GwVs1JfTQlTL+FeYvRlibmsF2LJbAe6FKsCE1bxwhmE=; b=i6OO+yPNHi0jhIeIRJ51Jy9wvHBLnKsHjdSrwWDUtY9/arTCQ7UU7mVOAA1+E38XiL flMxIY6rpCVYl/h3AceIog/adnLYUy9E6tcv9wTVPt0uwIrrHOJWKdp8gSVXwF58gqkj jwPsw7y14Vkl5OGZwgtThU5OXwaINciWCDVp6qMDGzeq+xRWYRGK77fbF6XRAfmpgPDC J339Ue+d/2EKRTkQ3W6Q0uPoIwcHSf8n1n4CkAjPGo+pp59bKsWlldobnywNkjB/VmZ7 JwqFgnFmZcfgi7eGpTk7vyXGcE04/kftkdZAbLoDQKgbHJ/R6gpbwAltfIf8FKny+OgH faNQ== X-Gm-Message-State: AOAM532Mfnq/uJuy2XsZ4NLI/HKQxD7SYEsSCLP6u89Lgmxr6CVvkaTN //dO2ftVb3baTemi2XmIPWFWGV5T8Saj26qjj7w+E6xP3U0= X-Google-Smtp-Source: ABdhPJyQr8wi0qE7w9YrKGdC6sNEynCwZqB0nVC+4SW8ghd1FS9SQdl4CFjLS+FYQNZeCa2NwwKdH0uiYyOb/L3BO+k= X-Received: by 2002:a9d:6502:: with SMTP id i2mr1727836otl.288.1597919473400; Thu, 20 Aug 2020 03:31:13 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Thu, 20 Aug 2020 12:35:31 +0200 Message-ID: To: Babel at IETF , babel-users Content-Type: multipart/alternative; boundary="0000000000009790b105ad4c9ebb" Archived-At: Subject: [babel] MAC auth. for Babel in babeld X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 10:31:17 -0000 --0000000000009790b105ad4c9ebb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I=E2=80=99ve rolled up my sleeves and finished my implementation of the MAC authentication protocol in babeld. It can be found on the branch "hmac" in https://github.com/MisterDA/babeld.git Or on the opened pull-request in the main repository at https://github.com/jech/babeld/pull/52 There is one bug that I=E2=80=99m aware of: sometimes the local configurati= on interface will respond "bad", letting the user think that there was an error during the parsing or the processing of the configuration, but everything happened correctly. There is one feature that I have not implemented (yet): expiring per-neighbour state (section 4.4) using the Hello history or a timer based on the last accepted packet. The code has not undergone review. No interoperability testing has been done. I=E2=80=99m also looking for feedback on the user interface. Here follows t= he manual page describing the new configuration options (underscores indicate user defined values). In particular, do you think that implementing keysets and allowing an unbounded number of keys is too much for babeld? Key rotation is done through the local configuration interface. MAC authentication for the Babel routing protocol This protocol provides basic security properties for the Babel routing protocol. The scope of this protocol is strictly limited: it only provides authentication (we assume that routing information is not confidential), it only supports symmetric keying, and it only allows for the use of a small number of symmetric keys on every link. Keys and keysets are reference-counted. They are discarded as soon as they are no longer referenced. Interface configuration mac {true|false} Enable MAC security on this interface. mac-verify {true|false} Check packet signatures, reject unsigned or incorrectly signed packets. The default is true. add-keyset _keyset-name_ Add the keyset _keyset-name_ to the set of keysets of this interface. rm-keyset _keyset-name_ Remove the keyset _keyset-name_ from the set of keysets of this interface. Global options key name _name_ algorithm {hmac-sha256|blake2s} value _value_ use {sign|verify|both} Configure a key for use with the mac interface option. The algorithm is either hmac-sha256 or blake2s. The value is a hexadecimal string (up to 64 bytes for hmac-sha256 or up to 32 bytes for blake2s). The use specifies whether the key is used to sign packets, verify packets, or both (signing and verifying packets). keyset _name_ Create an empty keyset. keyset-add-key _keyset-name_ _key-name_ Add the key _key-name_ to the keyset _keyset-name_. keyset-rm-key _keyset-name_ _key-name_ Remove the key _key-name_ from the keyset _keyset-name_. Thanks! -- Antonin --0000000000009790b105ad4c9ebb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

I=E2=80=99ve rolled up my sleeves an= d finished my implementation of the MAC
authentication protocol in babel= d.

It can be found on the branch "hmac" in

=C2=A0 = =C2=A0 https://github.co= m/MisterDA/babeld.git

Or on the opened pull-request in the main = repository at

=C2=A0 =C2=A0 https://github.com/jech/babeld/pull/52


There is o= ne bug that I=E2=80=99m aware of: sometimes the local configuration
inte= rface will respond "bad", letting the user think that there was a= n
error during the parsing or the processing of the configuration, buteverything happened correctly.

There is one feature that I have no= t implemented (yet): expiring
per-neighbour state (section 4.4) using th= e Hello history or a timer
based on the last accepted packet.

The= code has not undergone review. No interoperability testing has
been don= e.

I=E2=80=99m also looking for feedback on the user interface. Here= follows the
manual page describing the new configuration options (under= scores
indicate user defined values).

In particular, do you think= that implementing keysets and allowing an
unbounded number of keys is t= oo much for babeld?

Key rotation is done through the local con= figuration interface.


=C2=A0 =C2=A0MAC authentication for t= he Babel routing protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0This protocol provi= des basic security properties for the Babel
=C2=A0 =C2=A0 =C2=A0 =C2=A0r= outing protocol. The scope of this protocol is strictly
=C2=A0 =C2=A0 = =C2=A0 =C2=A0limited: it only provides authentication (we assume that
= =C2=A0 =C2=A0 =C2=A0 =C2=A0routing information is not confidential), it onl= y supports
=C2=A0 =C2=A0 =C2=A0 =C2=A0symmetric keying, and it only allo= ws for the use of a small
=C2=A0 =C2=A0 =C2=A0 =C2=A0number of symmetric= keys on every link.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Keys and keysets are= reference-counted. They are discarded as
=C2=A0 =C2=A0 =C2=A0 =C2=A0soo= n as they are no longer referenced.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Inter= face configuration

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mac {tru= e|false}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Enable MAC security on this interface.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0mac-verify {true|false}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Check packet signatures, reject unsigned or
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 incorrectly = signed packets. The default is true.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0add-keyset _keyset-name_
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Add the keyset _keyset-name_ to the set of keys= ets
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of th= is interface.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rm-keyset _ke= yset-name_
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Remove the keyset _keyset-name_ from the set of
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 keysets of this interface.
=C2=A0 =C2=A0 =C2=A0 =C2=A0Global options

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0key name _name_ algorithm {hmac-sha256|blake2s} value
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_value_ use {sign|verify|both}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Configure a = key for use with the mac interface
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 option. The algorithm is either hmac-sha256 or<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 blake2s. = The value is a hexadecimal string (up to 64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bytes for hmac-sha256 or up to 32 bytes = for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 blake= 2s). The use specifies whether the key is used
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to sign packets, verify packets, or = both (signing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 and verifying packets).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0keyset _name_
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Create an empty keyset.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0keyset-add-key _keyset-name_ _key-name_
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Add the key _key-name_ to the key= set _keyset-name_.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keyset-r= m-key _keyset-name_ _key-name_
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 Remove the key _key-name_ from the keyset
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _keyset-name_.
<= br>
Thanks!

-- Antonin
--0000000000009790b105ad4c9ebb-- From nobody Thu Aug 20 09:42:16 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1643A08A6; Thu, 20 Aug 2020 09:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLknocAvu-Ie; Thu, 20 Aug 2020 09:42:13 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C143A0890; Thu, 20 Aug 2020 09:42:12 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 07KGg9M5021392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Aug 2020 18:42:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 07KGg9WX005962; Thu, 20 Aug 2020 18:42:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C7FB2ACF8C; Thu, 20 Aug 2020 18:42:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id XGVMdMg1svqT; Thu, 20 Aug 2020 18:42:08 +0200 (CEST) Received: from pirx.irif.fr (unknown [37.164.235.12]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 99026ACF89; Thu, 20 Aug 2020 18:42:07 +0200 (CEST) Date: Thu, 20 Aug 2020 18:42:05 +0200 Message-ID: <87blj546ci.wl-jch@irif.fr> From: Juliusz Chroboczek To: Erik Kline Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake In-Reply-To: <159782259266.4862.8769299602644465106@ietfa.amsl.com> References: <159782259266.4862.8769299602644465106@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 20 Aug 2020 18:42:09 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 20 Aug 2020 18:42:09 +0200 (CEST) X-Miltered: at korolev with ID 5F3EA7E1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F3EA7E1.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F3EA7E1.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F3EA7E1.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 : 5F3EA7E1.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F3EA7E1.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Erik Kline's No Objection on draft-ietf-babel-rfc6126bis-19: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 16:42:15 -0000 > * I couldn't find where any of the multi-byte numeric fields have their > endianness specified. Good catch, I'll fix that. > [ section 3.6 ] > * s/this kind of instabilities/these kind of instabilities/, I think By my ken, it can be either « this kind » or « these kinds ». I am not a native speaker, but I simply don't see how « these kind » can possibly be correct. Would you care to explain? > [ section 3.8.1.2 ] > * Perhaps s/it has finite metric/it has a finite metric/ I am fairly positive that this formulation is standard in mathematics. A quick Google search gives the following: A ring R is said to have finite length as a ring if it has finite length as left R module. any system which has finite size in at least one space dimension. one shows that X∩Γ has finite cardinal > [ section 4.4 ] > * Can a sub-TLV have sub-TLVs of its own? The document does not explicitly disallow sub-sub-TLVs, but it does not define their format. If, in the future, an extension is designed that needs sub-sub-TLVs, it will need to define their format itself. As a matter of fact, there exists one proposed extension that uses sub-sub-TLVs (draft-zhang-bier-babel-extensions). It uses sub-sub-TLVs that have the exact same format as OSPF sub-TLVs, so it uses sub-sub-TLVs in a format that is not culturally compatible with the rest of Babel. This is fine, and does not need to be regulated by 6126bis. > [ section 4.5 ] > * s/derived derived/derived/ Done, thanks. > [ Appendix A.3 ] > * s/results ;/results;/ maybe Done, thanks. — Juliusz From nobody Thu Aug 20 12:49:56 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521103A130E; Thu, 20 Aug 2020 12:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDis3oL3Yqxl; Thu, 20 Aug 2020 12:49:54 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896323A1307; Thu, 20 Aug 2020 12:49:53 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07KJnk2J014882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Aug 2020 15:49:49 -0400 Date: Thu, 20 Aug 2020 12:49:45 -0700 From: Benjamin Kaduk To: Juliusz Chroboczek Cc: Erik Kline , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs@ietf.org, Donald Eastlake , The IESG , babel@ietf.org Message-ID: <20200820194945.GO92412@kduck.mit.edu> References: <159782259266.4862.8769299602644465106@ietfa.amsl.com> <87blj546ci.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87blj546ci.wl-jch@irif.fr> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [babel] Erik Kline's No Objection on draft-ietf-babel-rfc6126bis-19: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 19:49:55 -0000 On Thu, Aug 20, 2020 at 06:42:05PM +0200, Juliusz Chroboczek wrote: > > [ section 3.8.1.2 ] > > > * Perhaps s/it has finite metric/it has a finite metric/ > > I am fairly positive that this formulation is standard in mathematics. The formulation regarding "finite" is, yes. "Metric" in mathematics tends to be used with a different meaning, though (roughly, a function that takes two points as inputs and returns the distance between them, but specifically the function and not the value it evaluates to). So, while I do not object to using the construction in this document, saying that it is "standard in mathematics" seems like not quite the right justification. -Ben > A quick Google search gives the following: > > A ring R is said to have finite length as a ring if it has finite length > as left R module. > > any system which has finite size in at least one space dimension. > > one shows that X∩Γ has finite cardinal From nobody Thu Aug 20 14:06:41 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7B13A1419; Thu, 20 Aug 2020 14:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2duM3Q4z1ch; Thu, 20 Aug 2020 14:06:38 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A32F3A1418; Thu, 20 Aug 2020 14:06:38 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id u63so3127506oie.5; Thu, 20 Aug 2020 14:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4VBRbfeIEcx+pq+/LgDupaZMEachotYON7+KqLuy53I=; b=r7f1oDb9SVvN9tejj9eqhLbZ751irkw/Iw9zLXTCsyRtSA/fi+pMSPf4lMzg0KG4oG 6EFnZABiFzJwYBRDD6TTy1JyUi8MCjaqxUDgeMYiLJGn+rWUQaN95rF3PFHhYEnJzhhR bLxJmIR5MoVaasFcJYlFKTs+5/hfDpQ/aLNQTu4VUifz+0jvRn/AxfcI5cE6sT2M+qgY SKXSrJorvu3kbMwcea0B8AdxfpTZPf2dQwn5DIwMQLuhdQ/ZiAHPqgHweD4J4y6XcFvy WXqLujDBrTqF0pfw+GAH0Nb1wel3DE/kl6M+psG65GO6mVJ/FSpNFkPrkRPFCl9A2JoR 5FwQ== 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=4VBRbfeIEcx+pq+/LgDupaZMEachotYON7+KqLuy53I=; b=tpuYNjDMJxmf+7mxdkCFC6D4GtOhrfanC+T59e+dDji/10IC68kQe+HvKRTMBl+D8D k78oLVR4tCALLEIF8xkMLmWUbWmjC/SWgP/AplHPyrvw3RuS+1zrIm2WQ2jYCYlPsXp2 nKf7Pek8ZZPXU/Nle5IHPkHTAHLxkJ8mVPi8yl24ZCqk82vIfyo3caLI7ltCiv+6CNSA JnOe0oBGfQRV115dB9c22Vskss46WtMzCMNWjw8/2Jpn6f2BDvCtmkvydhrqwL/VOTLq jBwGT/g9ZrbCRpiWRD2ePq1w78iWW6melhZLXjwB2Gy8fGkLMbtV5Y5pTycTK2E1cgXG +ORw== X-Gm-Message-State: AOAM533U54Miwrl5U4AYqBVxTsB/BBP6B1UR33BRfaBXhx6bFpCyabV1 Cu6Q3VXWqxjAz99zugPQEiSJ1haYn4tWQFQ+GI4= X-Google-Smtp-Source: ABdhPJzdmc6BmksXCbFOx1aV7ZygNufG8N+iodCdQRH7VrZyQv8IPP6ABSOGZhOUwrSB91e0s9vXOg6QedhLA5qKCac= X-Received: by 2002:aca:1117:: with SMTP id 23mr169019oir.97.1597957597314; Thu, 20 Aug 2020 14:06:37 -0700 (PDT) MIME-Version: 1.0 References: <159782259266.4862.8769299602644465106@ietfa.amsl.com> <87blj546ci.wl-jch@irif.fr> In-Reply-To: <87blj546ci.wl-jch@irif.fr> From: Erik Kline Date: Thu, 20 Aug 2020 14:06:26 -0700 Message-ID: To: Juliusz Chroboczek Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake Content-Type: multipart/alternative; boundary="000000000000f4408805ad557ef2" Archived-At: Subject: Re: [babel] Erik Kline's No Objection on draft-ietf-babel-rfc6126bis-19: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 21:06:40 -0000 --000000000000f4408805ad557ef2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > > [ section 3.6 ] > > > * s/this kind of instabilities/these kind of instabilities/, I think > > By my ken, it can be either =C2=AB this kind =C2=BB or =C2=AB these kinds= =C2=BB. I am not > a native speaker, but I simply don't see how =C2=AB these kind =C2=BB can= possibly > be correct. Would you care to explain? > You're quite right; I think "these kinds of " is what I should have suggested. > [ section 3.8.1.2 ] > > > * Perhaps s/it has finite metric/it has a finite metric/ > > I am fairly positive that this formulation is standard in mathematics. > A quick Google search gives the following: > > A ring R is said to have finite length as a ring if it has finite lengt= h > as left R module. > > any system which has finite size in at least one space dimension. > > one shows that X=E2=88=A9=CE=93 has finite cardinal > Sounding more mathy is good by me! I suspect there's no loss of clarity for the implementer one way or the other. > [ section 4.4 ] > > > * Can a sub-TLV have sub-TLVs of its own? > > The document does not explicitly disallow sub-sub-TLVs, but it does not > define their format. If, in the future, an extension is designed that > needs sub-sub-TLVs, it will need to define their format itself. > > As a matter of fact, there exists one proposed extension that uses > sub-sub-TLVs (draft-zhang-bier-babel-extensions). It uses sub-sub-TLVs > that have the exact same format as OSPF sub-TLVs, so it uses sub-sub-TLVs > in a format that is not culturally compatible with the rest of Babel. > This is fine, and does not need to be regulated by 6126bis. > Sounds good. Not expressly forbidden meant to me that someone might propose it later. But it sounds like that's "Working As Intended". =3D) Thanks. --000000000000f4408805ad557ef2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> [ section 3.6 ]

> * s/this kind of instabilities/these kind of instabilities/, I think
By my ken, it can be either =C2=AB this kind =C2=BB or =C2=AB these kinds = =C2=BB.=C2=A0 I am not
a native speaker, but I simply don't see how =C2=AB these kind =C2=BB c= an possibly
be correct.=C2=A0 Would you care to explain?

You're quite right; I think "these kinds of <plural thing= >" is what I should have suggested.

> [ section 3.8.1.2 ]

> * Perhaps s/it has finite metric/it has a finite metric/

I am fairly positive that this formulation is standard in mathematics.
A quick Google search gives the following:

=C2=A0 A ring R is said to have finite length as a ring if it has finite le= ngth
=C2=A0 as left R module.

=C2=A0 any system which has finite size in at least one space dimension.
=C2=A0 one shows that X=E2=88=A9=CE=93 has finite cardinal
=

Sounding more mathy is good by me!=C2=A0 I suspect ther= e's no loss of clarity for the implementer one way or the other.
<= div>
> [ section 4.4 ]

> * Can a sub-TLV have sub-TLVs of its own?

The document does not explicitly disallow sub-sub-TLVs, but it does not
define their format.=C2=A0 If, in the future, an extension is designed that=
needs sub-sub-TLVs, it will need to define their format itself.

As a matter of fact, there exists one proposed extension that uses
sub-sub-TLVs (draft-zhang-bier-babel-extensions).=C2=A0 It uses sub-sub-TLV= s
that have the exact same format as OSPF sub-TLVs, so it uses sub-sub-TLVs in a format that is not culturally compatible with the rest of Babel.
This is fine, and does not need to be regulated by 6126bis.

Sounds good.

Not expressly fo= rbidden meant to me that someone might propose it later.=C2=A0 But it sound= s like that's "Working As Intended".=C2=A0 =3D)
Thanks.
--000000000000f4408805ad557ef2-- From nobody Fri Aug 21 13:08:52 2020 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 F102B3A120A; Fri, 21 Aug 2020 13:08:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <159804052095.453.17199944115463482171@ietfa.amsl.com> Date: Fri, 21 Aug 2020 13:08:40 -0700 Archived-At: Subject: [babel] Martin Duke's No Record on draft-ietf-babel-rfc6126bis-19: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 20:08:47 -0000 Martin Duke has entered the following ballot position for draft-ietf-babel-rfc6126bis-19: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One nit: 3.7.2 In the last paragraph, selection of a next hop is listed as both a "MAY" and a "SHOULD NOT". I suppose that this not logically inconsistent, but the context certainly suggests that's both significant and minor, which doesn't make sense. From nobody Fri Aug 21 13:09:17 2020 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 482A73A1286; Fri, 21 Aug 2020 13:09:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <159804054475.31858.7651107368431960573@ietfa.amsl.com> Date: Fri, 21 Aug 2020 13:09:05 -0700 Archived-At: Subject: [babel] Martin Duke's No Objection on draft-ietf-babel-rfc6126bis-19: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 20:09:12 -0000 Martin Duke has entered the following ballot position for draft-ietf-babel-rfc6126bis-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One nit: 3.7.2 In the last paragraph, selection of a next hop is listed as both a "MAY" and a "SHOULD NOT". I suppose that this not logically inconsistent, but the context certainly suggests that's both significant and minor, which doesn't make sense. From nobody Fri Aug 21 13:35:12 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E193A1234; Fri, 21 Aug 2020 13:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjC5QPNsTo2f; Fri, 21 Aug 2020 13:34:59 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BE53A1239; Fri, 21 Aug 2020 13:34: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 07LKYupb020249; Fri, 21 Aug 2020 22:34:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2EE91B2707; Fri, 21 Aug 2020 22:34:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 6p-_B1Bj3koo; Fri, 21 Aug 2020 22:34:54 +0200 (CEST) Received: from pirx.irif.fr (unknown [37.172.34.76]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 06E49B2703; Fri, 21 Aug 2020 22:34:53 +0200 (CEST) Date: Fri, 21 Aug 2020 22:34:52 +0200 Message-ID: <878se7hh5f.wl-jch@irif.fr> From: Juliusz Chroboczek To: Martin Duke Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake In-Reply-To: <159804054475.31858.7651107368431960573@ietfa.amsl.com> References: <159804054475.31858.7651107368431960573@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, 21 Aug 2020 22:34:56 +0200 (CEST) X-Miltered: at korolev with ID 5F402FF0.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F402FF0.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 : 5F402FF0.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] Martin Duke's No Objection on draft-ietf-babel-rfc6126bis-19: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 20:35:01 -0000 > 3.7.2 In the last paragraph, selection of a next hop is listed as both a "MAY" > and a "SHOULD NOT". Hmm. What this paragraph is meant to say is that it MAY send an update when the metric changes, including due to a new next hop being selected, but it SHOULD NOT if the next hop changes without causing a significant change in the metric. I'll try to make it clearer. -- Juliusz From nobody Mon Aug 24 15:28:38 2020 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 93A7D3A0E43; Mon, 24 Aug 2020 15:28:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <159830811357.20683.8180824142008852554@ietfa.amsl.com> Date: Mon, 24 Aug 2020 15:28:33 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-20.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 22:28:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : The Babel Routing Protocol Authors : Juliusz Chroboczek David Schinazi Filename : draft-ietf-babel-rfc6126bis-20.txt Pages : 70 Date : 2020-08-24 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 24 15:40:11 2020 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 BB11E3A0E41; Mon, 24 Aug 2020 15:40:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <159830880573.4661.958880865029565268@ietfa.amsl.com> Date: Mon, 24 Aug 2020 15:40:05 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-hmac-11.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 22:40:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : MAC authentication for the Babel routing protocol Authors : Clara Do Weronika Kolodziejak Juliusz Chroboczek Filename : draft-ietf-babel-hmac-11.txt Pages : 21 Date : 2020-08-24 Abstract: This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document obsoletes RFC 7298. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-hmac-11 https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-hmac-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 26 02:46:38 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8F23A1148 for ; Wed, 26 Aug 2020 02:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDdr3skWBE8O for ; Wed, 26 Aug 2020 02:46:34 -0700 (PDT) Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 A0B7A3A1147 for ; Wed, 26 Aug 2020 02:46:34 -0700 (PDT) Received: by mail-oo1-xc32.google.com with SMTP id y30so305450ooj.3 for ; Wed, 26 Aug 2020 02:46:34 -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=eQ5oYafWE2yTI5cgKVfHNdPWiIfj3L5rn3UPj0Kf1lQ=; b=EB9J47a/1oTHeZz4W3NT0oCtL0ZEGYypadLl18uqXLx8RKbgrEQY1ECYSJqDUaYajQ JI1IRZVCd7TnrguH8MsuxQHSzoUdSgC/vhGo3QBWFT+dq79E02jZsgf7FudowlQr8H7u /wh86dr3ZEfNw2q5wlqaYW8ZDJwpNBJu5TNlb4w1JPEr4gvmOxSlqskiGfV/hhmwV4yI Y3Jc1E+GvVeprSWZQzbP0Yjlkue1WFXGWs/heVPvddIvDO/HbKjHOi5uizJK/7YvWBoh L2UV1X9na5nLRI8NFiMSo25tX7P3ewNHcK1/wMQXmbdiu9kTxao93k/Q4+zPnNWdhjXg lJTw== 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=eQ5oYafWE2yTI5cgKVfHNdPWiIfj3L5rn3UPj0Kf1lQ=; b=NXQVyVDrYDFFp6Ij7+8QHJBFzsxJ/gVLuFKv6EKo2v0B/AKIS8q+E+zdpUpMofdeXs daytvqNw3htP+oHJL9RAU/k/fnXk9PcN3/+pcOXxlT3mf1u/6L+2/uS6HsYY5gDyBIq8 x5HKUSd3bFv1kCmj4sjwsXXyf9sMa3xWK1ZtLP2nzVYZectHT/BcC8QoKjSZn5H6cIWt pqil/ETfv0VJhBcOi0Nvh1YGw3n7WgC+PojLO8oj5NZeRvySHmlXLILzvniCvjBMwiSp dDvoowK5m4SI544UaK58jenkjiXH1llp0Ymd8DHf17IJdynCVQ3rFpAaFMMQi42qh38j m9JA== X-Gm-Message-State: AOAM531C8xPyZRNsJhkdJPRw6pSD67jDbYcSagIE/dIFPOa4taV+rDa0 13FGECyl2Ao3HCKgXZ2GQxywDpza56oPT64gZL45R0ItfmY= X-Google-Smtp-Source: ABdhPJx5/UotIdfbD5n3Oql/bQOSo5z2pTIsgcp0YHPG1rjOtPy0mLxgkIpisO72TC+/QoEOxHcf9EDANqcWHVV2ZTM= X-Received: by 2002:a4a:3312:: with SMTP id q18mr91449ooq.20.1598435193548; Wed, 26 Aug 2020 02:46:33 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Wed, 26 Aug 2020 11:51:13 +0200 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000e8752205adc4b161" Archived-At: Subject: [babel] Comments on the MAC authentication for Babel draft X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 09:46:37 -0000 --000000000000e8752205adc4b161 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, I have some comments on the MAC authentication for Babel draft. The first three date from 2020-12-28, the others are new. 1. Key length This is the change I'm proposing in =C2=A77: Keys must be chosen in a manner that makes them difficult to guess. -Ideally, they should have a length of 32 octets (both for HMAC-SHA256 -and Blake2s), and be chosen randomly. +Ideally, they should be chosen randomly, and have the maximum key +length supported by the MAC algorithm (32 octets for keyed BLAKE2S) +or no less than the block size of the MAC algorithm (64 octets for +HMAC-SHA256). 2. Digest length Reading the length of the MAC TLV in order to compute a MAC of this length is not compliant with the protocol (=C2=A74.3) since MACs are computed without looking into the packet. > Then, for each key configured on the receiving interface, the > receiver computes the MAC of the packet. It then compares every > generated MAC against every MAC included in the packet; Still, it was an error I was almost going to make. I propose the following change to ensure that we're always using the maximum digest length of the MAC algorithm. This is the change I'm proposing in =C2=A74.1: implementation MUST implement HMAC-SHA256 as defined in and Section 2 of , SHOULD implement keyed BLAKE2s , and MAY impleme= nt other MAC algorithms. +The length of the MAC MUST be the maximum MAC length computable by +the MAC algorithm (32 octets for both HMAC-SHA256 and keyed +BLAKE2S). 3. Lazy computation With the idea that computing a MAC is more costly than comparing MACs, and that there's a very limited amount of MACs to check, I propose we lazily compute MACs. Instead of computing the MAC for every key on packet reception, we compute the MAC with the first key, then check it against the MACs carried by the packet. If there's a match, the packet is immediately accepted. If there's no match, we the proceed to the next key until all keys are exhausted, and the packet is rejected. This is the change I'm proposing in =C2=A74.3: -Then, for each key configured on the receiving interface, the -receiver computes the MAC of the packet. It then compares every -generated MAC against every MAC included in the packet; if there is -at least one match, the packet passes the MAC test; if there is none, -the packet MUST be silently dropped and processing stops at this -point. +Then, for each key configured on the receiving interface, the +receiver computes the MAC of the packet and compares it against every +MAC included in the packet; if there is at least one match, the +packet passes the MAC test; if there is none, the receiver proceeds +with the next key. If none of the MAC matched, the packet MUST be +silently dropped and processing stops at this point. 4. Accepting Challenges When receiving a challenge reply, a node must check if there was a challenge in progress before validating the challenge. =C2=A7 3.2 Neighbour table > The Nonce and expiry timer are initially undefined =C2=A7 4.3.1.3. Receiving challenge replies > If no challenge is in progress, i.e., if there is no Nonce stored in > the Neighbour Table entry or the Challenge timer has expired, the > Challenge Reply MUST be silently ignored and the challenge has > failed. However the text does not explicitly describe if there are changes to be made to the overall state when the challenge succeeds. > Otherwise, the node compares the Nonce contained in the Challenge > Reply with the Nonce contained in the Neighbour Table entry. If the > two are equal (they have the same length and content), then the > challenge has succeeded; otherwise, the challenge has failed. As it is not possible to have a running or expired timer and an uninitialised Nonce field, I think that the timer should be initialised in the "expired" state. The "challenge is in progress" test can be simplified to "is the timer expired?", and then if the challenge succeeds, the timer should be set into the "expired" state, so that duplicated or incorrect challenge replies are rejected. 5. Replying to challenges Section 4.3.1.2. Replying to challenges, the sentence > A challenge sent to a multicast address MUST be silently ignored. could be moved earlier, as it describes a case where the challenge request should be ignored, but it is after the text indicating how to construct and send a challenge reply. 6. Timers I was confused at first between the "challenge expiry timer", the two rate limits, and the neighbour state expiry timer. I suggest, for consistency, the following changes: section 3.2: - The Nonce and expiry timer are initially undefined + The Nonce and challenge expiry timer are initially undefined section 4.3.1.3 - the Challenge timer has expired + the challenge timer has expired 7. TLV names shouldn't be pluralised Section 4.3 - ignored except PC TLVs, Challenge Requests and Challenge Replies. + ignored except PC, Challenge Request, and Challenge Reply TLVs. - 4.3.1. Challenge Requests and Replies + 4.3.1. Challenge requests and replies 8. Consistency Section 6.2 replace "4 octet" with "4-octet" (single dash) Section 7 - nonces included in challenge requests and responses can + nonces included in challenge requests and replies can 9. Relations with the Information Model The MAC draft defines (amongst other) three optionaly tunable parameters: - the rate limit for sending Challenge Replies; - the rate limit for sending Challenge Requests; - various strategies for expiring neighbour state, with their own tunable parameters. Should they be reflected in the models? All the best, -- Antonin --000000000000e8752205adc4b161 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

I have some comments on the MAC authenti= cation for Babel draft.
The first three date from 2020-12-28, the others= are new.


1. Key length

This is the change I'm propo= sing in =C2=A77:

=C2=A0Keys must be chosen in a manner that makes th= em difficult to guess.
-Ideally, they should have a length of 32 octets = (both for HMAC-SHA256
-and Blake2s), and be chosen randomly.
+Ideally= , they should be chosen randomly, and have the maximum key
+length suppo= rted by the MAC algorithm (32 octets for keyed BLAKE2S)
+or no less than= the block size of the MAC algorithm (64 octets for
+HMAC-SHA256).

2. Digest length

Reading the length of the MAC TLV in order to= compute a MAC of this
length is not compliant with the protocol (=C2=A7= 4.3) since MACs are
computed without looking into the packet.

>= ; Then, for each key configured on the receiving interface, the
> rec= eiver computes the MAC of the packet. It then compares every
> genera= ted MAC against every MAC included in the packet;

Still, it was an e= rror I was almost going to make. I propose the
following change to ensur= e that we're always using the maximum digest
length of the MAC algor= ithm.

This is the change I'm proposing in =C2=A74.1:

=C2= =A0implementation MUST implement HMAC-SHA256 as defined in
=C2=A0<xre= f target=3D"RFC6234"/> and Section 2 of <xref target=3D&quo= t;RFC2104"/>,
=C2=A0SHOULD implement keyed BLAKE2s <xref targ= et=3D"RFC7693"/>, and MAY implement
=C2=A0other MAC algorit= hms.
+The length of the MAC MUST be the maximum MAC length computable by=
+the MAC algorithm (32 octets for both HMAC-SHA256 and keyed
+BLAKE2= S).


3. Lazy computation

With the idea that computing a MA= C is more costly than comparing MACs,
and that there's a very limite= d amount of MACs to check, I propose we
lazily compute MACs. Instead of = computing the MAC for every key on
packet reception, we compute the MAC = with the first key, then check it
against the MACs carried by the packet= . If there's a match, the packet
is immediately accepted. If there&#= 39;s no match, we the proceed to the
next key until all keys are exhaust= ed, and the packet is rejected.

This is the change I'm proposing= in =C2=A74.3:

-Then, for each key configured on the receiving inter= face, the
-receiver computes the MAC of the packet.=C2=A0 It then compar= es every
-generated MAC against every MAC included in the packet; if the= re is
-at least one match, the packet passes the MAC test; if there is n= one,
-the packet MUST be silently dropped and processing stops at this-point.
+Then, for each key configured on the receiving interface, the=
+receiver computes the MAC of the packet and compares it against every<= br>+MAC included in the packet; if there is at least one match, the
+pac= ket passes the MAC test; if there is none, the receiver proceeds
+with t= he next key.=C2=A0 If none of the MAC matched, the packet MUST be
+silen= tly dropped and processing stops at this point.


4. Accepting Cha= llenges

When receiving a challenge reply, a node must check if there= was a
challenge in progress before validating the challenge.

=C2= =A7 3.2 Neighbour table
> The Nonce and expiry timer are initially un= defined

=C2=A7 4.3.1.3. Receiving challenge replies
> If no ch= allenge is in progress, i.e., if there is no Nonce stored in
> the Ne= ighbour Table entry or the Challenge timer has expired, the
> Challen= ge Reply MUST be silently ignored and the challenge has
> failed.
=
However the text does not explicitly describe if there are changes
t= o be made to the overall state when the challenge succeeds.

> Oth= erwise, the node compares the Nonce contained in the Challenge
> Repl= y with the Nonce contained in the Neighbour Table entry. If the
> two= are equal (they have the same length and content), then the
> challe= nge has succeeded; otherwise, the challenge has failed.

As it is not= possible to have a running or expired timer and an
uninitialised Nonce = field, I think that the timer should be
initialised in the "expired= " state. The "challenge is in progress"
test can be simpl= ified to "is the timer expired?", and then if the
challenge su= cceeds, the timer should be set into the "expired" state,
so t= hat duplicated or incorrect challenge replies are rejected.


5. R= eplying to challenges

Section 4.3.1.2. Replying to challenges, the s= entence

> A challenge sent to a multicast address MUST be silentl= y ignored.

could be moved earlier, as it describes a case where the = challenge
request should be ignored, but it is after the text indicating= how to
construct and send a challenge reply.


6. Timers
I was confused at first between the "challenge expiry timer", t= he two
rate limits, and the neighbour state expiry timer. I suggest, for=
consistency, the following changes:

section 3.2:
- The Nonce = and expiry timer are initially undefined
+ The Nonce and challenge expir= y timer are initially undefined

section 4.3.1.3
- the Challenge t= imer has expired
+ the challenge timer has expired


7. TLV nam= es shouldn't be pluralised

Section 4.3
- ignored except PC TL= Vs, Challenge Requests and Challenge Replies.
+ ignored except PC, Chall= enge Request, and Challenge Reply TLVs.

- 4.3.1.=C2=A0 Challenge Req= uests and Replies
+ 4.3.1.=C2=A0 Challenge requests and replies

<= br>8. Consistency

Section 6.2
replace "4 octet" with &q= uot;4-octet" (single dash)

Section 7
- nonces included in ch= allenge requests and responses can
+ nonces included in challenge reques= ts and replies can


9. Relations with the Information Model
The MAC draft defines (amongst other) three optionaly tunable parameters:=
- the rate limit for sending Challenge Replies;
- the rate limit for= sending Challenge Requests;
- various strategies for expiring neighbour= state, with their own
=C2=A0 tunable parameters.
Should they be refl= ected in the models?


All the best,

-- Antonin
--000000000000e8752205adc4b161-- From nobody Wed Aug 26 03:26:19 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCEE3A0A87 for ; Wed, 26 Aug 2020 03:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6hsVGOCeH7F for ; Wed, 26 Aug 2020 03:26:15 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B193A0A40 for ; Wed, 26 Aug 2020 03:26:14 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 07QAQB5K031756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Aug 2020 12:26:11 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 07QAQB1B018723; Wed, 26 Aug 2020 12:26:11 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B95DDBD3C6; Wed, 26 Aug 2020 12:26:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VEln2XEneDBO; Wed, 26 Aug 2020 12:26:10 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5FB0EBD3C1; Wed, 26 Aug 2020 12:26:07 +0200 (CEST) Date: Wed, 26 Aug 2020 12:26:05 +0200 Message-ID: <87zh6hem9u.wl-jch@irif.fr> From: Juliusz Chroboczek To: Antonin =?ISO-8859-1?Q?D=E9cimo?= Cc: 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=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 26 Aug 2020 12:26:11 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 26 Aug 2020 12:26:11 +0200 (CEST) X-Miltered: at korolev with ID 5F4638C3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F4638C3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F4638C3.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F4638C3.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 : 5F4638C3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F4638C3.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] Comments on the MAC authentication for Babel draft X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 10:26:18 -0000 Dear Antonin, While many of these are good changes, Donald is telling me that at this stage we're not making any changes that are not actual bug fixes. (He's been telling me that for the best part of a year now, sigh.) Antonin -- what we're dealing with here is a hostile bureaucratic organisation (similar to our University's administration), so we must choose our battles. I don't think any of the battles below are worth fighting. > 1. Key length I disagree. Using 64 octets for SHA-256 gives no additional security. https://crypto.stackexchange.com/questions/34864/key-size-for-hmac-sha256 > 2. Digest length > Reading the length of the MAC TLV in order to compute a MAC of this > length is not compliant with the protocol (§4.3) since MACs are > computed without looking into the packet. No. The digest length is part of the algorithm. The algorithm is carried out-of-band. In other words -- when a key is configured in a router, it is configured together with the associated algorithm. The algorithm implies a digest length. For example, SHA-256 truncated to 128 bits is a different algorithm than SHA-256 with full digests. I agree that this could be made clearer, but we're not tweaking this at this stage. > 3. Lazy computation This is already legal — your proposed tweak doesn't violate any of the MUST in this paragraph. I agree that your wording is better, but we're not making this change at this stage. > 4. Accepting Challenges > When receiving a challenge reply, a node must check if there was a > challenge in progress before validating the challenge. > However the text does not explicitly describe if there are changes > to be made to the overall state when the challenge succeeds. Right. The obvious implementation strategy is to discard the challenge state after a challenge has succeded. Not doing that does not cause any security issues (it's not required by the proof of correctness). I think we should add « SHOULD discard the state » here, but it requires Donald's permission. > I was confused at first between the "challenge expiry timer", the two > rate limits, and the neighbour state expiry timer. I suggest, for > consistency, the following changes: Right. Unfortunately, we're no longer allowed to improve the wording. > 5. Replying to challenges > Section 4.3.1.2. Replying to challenges, the sentence [...] could be moved > earlier Right again. Not worth fighting for, IMHO. > 7. TLV names shouldn't be pluralised Same. > The MAC draft defines (amongst other) three optionaly tunable parameters: [...] > Should they be reflected in the models? No. The protocol is robust enough that the exact values are irrelevant to its security. -- Juliusz From nobody Wed Aug 26 05:22:11 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EE73A122F for ; Wed, 26 Aug 2020 05:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A9AIH1bjuig for ; Wed, 26 Aug 2020 05:22:09 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 CE4103A122E for ; Wed, 26 Aug 2020 05:22:08 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id z9so1566215wmk.1 for ; Wed, 26 Aug 2020 05:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:cc:subject:from:to:date :message-id:in-reply-to; bh=eC5ncwmby64OAouDFJaQxco+dhAK5SKo3vgYmErMpaM=; b=AbVMyiPgrTOLK6vjAwR4ng/Ofu3yLWQw5YlvSVqNZtFBinAcGMKdOGS4CBPcRPARRw DbmxjrofaMlAYNuvmwg0Q5fxltHwllygYe9nmYIvgqSE/N3GfRxvCl7KA5Ld2YHjCtB4 IK1292AW/PTFPLaTFC8Rk6PhBvqYKcsRTJi7JlSf8Kn9kTG0L2cbm9KsgEWGHXBcWBog EpCBdrHLs6uMTOJMLDPUlsezwObIO89KFN9448ztH3INyFm4DF6budUUD+p9oAcakdUP caWyLyhXakUW22+XENK6rtVPiW7L0OSaoU3nHM5Wu+ez8d3PRUWOP2afXSEwWQJRpFEQ 2TKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding:cc :subject:from:to:date:message-id:in-reply-to; bh=eC5ncwmby64OAouDFJaQxco+dhAK5SKo3vgYmErMpaM=; b=SgyNSowh9/FY9bpEtCo8iuF+zY7xCwx+QKp7F1nRN95l6uKmgqmorD0t6wjCNBOZHR RZ/QlIfYKiTT65dYpWN9zKb2QfRe9zIBRCPxA5a7pfu4MPU3btn/w/63toWiWPsFqboa zI00zVEnjPTenbhzzj2DwUTyat/Y3eyqYEfBuMJha1yKj5P65jAicmyEGrcZq0Fc2cyN GC9iBxaMCRAFwI8UDzdbOSUlr3GLP/M0/+Iwx+TOogUGyGTGZXgfo2UtULIKIxBQ6y0+ 6ND6GrxSIVknuO2iTXijpTOx6eEtgMxaZMfPJrm/ubLlXYNlEsqHLiblscqlozzJV7bl zB8A== X-Gm-Message-State: AOAM533yLpVCPpWReryJf3WGt9ZyDx1Ldtp8ijHTQ4tvtVZIW0T7rHS5 7RXWKSqnrrwllh+QuFg/aqY= X-Google-Smtp-Source: ABdhPJzyvatT75qBCBf+2ZDpmxMIy8iHHmeE6cgZT4gGIOmO7ealXBlumDDopNubRHxLgEnbfD9deg== X-Received: by 2002:a7b:c197:: with SMTP id y23mr6739489wmi.48.1598444526933; Wed, 26 Aug 2020 05:22:06 -0700 (PDT) Received: from localhost (176-190-174-144.abo.bbox.fr. [176.190.174.144]) by smtp.gmail.com with ESMTPSA id n18sm5342517wrp.58.2020.08.26.05.22.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Aug 2020 05:22:06 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Cc: "Babel at IETF" From: =?utf-8?q?Antonin_D=C3=A9cimo?= To: "Juliusz Chroboczek" Date: Wed, 26 Aug 2020 13:52:24 +0200 Message-Id: In-Reply-To: <87zh6hem9u.wl-jch@irif.fr> Archived-At: Subject: Re: [babel] Comments on the MAC authentication for Babel draft X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 12:22:11 -0000 > > 1. Key length > > I disagree. Using 64 octets for SHA-256 gives no additional security. > > https://crypto.stackexchange.com/questions/34864/key-size-for-hmac-sha256 Ok, thanks. > > 2. Digest length > when a key is configured in a router, it is configured together with > the associated algorithm. The algorithm implies a digest length. Ah, I see. This is just what I had missed. Thanks for reviewing my comments. I don=E2=80=99t see any bugs left in the draft. I=E2=80=99m sorry to see that it=E2=80=99s too late for clarificatio= ns. -- Antonin From nobody Wed Aug 26 11:09:02 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F1B3A1002 for ; Wed, 26 Aug 2020 11:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kjQwnWgwry6 for ; Wed, 26 Aug 2020 11:08:59 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E38A3A0FFD for ; Wed, 26 Aug 2020 11:08:59 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id 12so1481071lfb.11 for ; Wed, 26 Aug 2020 11:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xtGSbu6zEUAILEhisfrkTfZgyKNfdxRv+BEmYXYBDKM=; b=VwsuGdzHpkwhU02SBdcFdItPywfTz2oTjTFd/MfM5Qub3oOa3moSfDl9qkiEuG8+5K DLd5uFxGMQ9E9yUPX3HB6jNIZ4b+JGny9x3gzkGIPQMdN2158t+QmRZUDUp8pL1ulOPt FfuuVVn97NfaNVmei3Nl7DlGOQ5ovYOU+soaamY2s0fmP5yLXU7SjWJ/ogRlMpvIbvZW jj0v4CwqXLdfg01dAR0QewjmCrJQEJUuza887kZzE6QGQBFH6xcrcSAo56SafgG7V4yQ Xo+hMQRaL1Ulc/AVL8ydmX9NNl7YTkvYBlEiT+kGnsOg7uFqO5dhnFovuTFnBDNfSVvW yt7w== 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=xtGSbu6zEUAILEhisfrkTfZgyKNfdxRv+BEmYXYBDKM=; b=JabwHwCIS7q9MPSVAY0c0F+rV5hqa7Kv8d0NehmX3GY+HMejWfFgLnU0b1g7ee5P95 /HGbD/eCReQkopC91bTvAgjPVHAS8z724k3i3JMSBOyTpQ6BVCbAdWrnlMmAppw+DytD +0phcXyeSnqX/W0c6WLrYktKYU6HYnQ+p5/Q97CvqQmev0MEplhsU6Xj4nRuFh+82Phc H1hh3wUL9yPJCHL9LQfWf/0gaxLOnDA1Xq794acU+7b3Dc8GvdPun4pjjPLLl2Rna61H wN+fl8ndt0IcBLIroPaZAFQZ28NKY7kfE59ngfxcFY289HSag+FjKHKX4NXruqW0sI1m evrw== X-Gm-Message-State: AOAM5303hbvVg/7Ly1KGTsau1BU9dyvJRHBhnJT6LzAFv9SIpqB5jFVJ FA2Hm5WbK83Z/G3dnScnu5jdxPMru3auFLwPwFs= X-Google-Smtp-Source: ABdhPJwW8JuePkr4/SRuqEnayJuJtcuEC6UItKuY8VyqkiZ5GzTqs3+nS9nuzIDcNVWL8Hq53TkpmaJcdOqFWdbyglc= X-Received: by 2002:a05:6512:2107:: with SMTP id q7mr7988124lfr.160.1598465337043; Wed, 26 Aug 2020 11:08:57 -0700 (PDT) MIME-Version: 1.0 References: <87zh6hem9u.wl-jch@irif.fr> In-Reply-To: From: David Schinazi Date: Wed, 26 Aug 2020 11:08:46 -0700 Message-ID: To: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Cc: Juliusz Chroboczek , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000099b5f005adcbb6db" Archived-At: Subject: Re: [babel] Comments on the MAC authentication for Babel draft X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 18:09:01 -0000 --00000000000099b5f005adcbb6db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To be slightly pedantic about the IETF process here (chairs, please correct me if I'm wrong), it's not too late to make editorial changes to the document. It is too late to make big technical changes, as that would require the relevant ADs to re-review the document, but as authors you can feel free to clarify the wording. Another option is that you'll be able to also change wording during AUTH48 (one of the very last steps of the process where the authors go back and forth with the RFC Editor to get all the editorial details right). All that will be required is for the responsible AD (in this case Martin Vigoureux) to review the AUTH48 changes and confirm that they are editorial. I would suggest making small editorial changes now right before we send this off to the RFC Editor. David On Wed, Aug 26, 2020 at 5:22 AM Antonin D=C3=A9cimo wrote: > > > 1. Key length > > > > I disagree. Using 64 octets for SHA-256 gives no additional security. > > > > > https://crypto.stackexchange.com/questions/34864/key-size-for-hmac-sha256 > > Ok, thanks. > > > > 2. Digest length > > when a key is configured in a router, it is configured together with > > the associated algorithm. The algorithm implies a digest length. > > Ah, I see. This is just what I had missed. > > > Thanks for reviewing my comments. I don=E2=80=99t see any bugs left in th= e > draft. I=E2=80=99m sorry to see that it=E2=80=99s too late for clarificat= ions. > > -- Antonin > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --00000000000099b5f005adcbb6db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be slightly pedantic about the IETF process here
(c= hairs, please correct me if I'm wrong), it's not too late
to make editorial changes to the document. It is too
late to mak= e big technical changes, as that would require
the relevant ADs t= o re-review the document, but as authors
you can feel free to cla= rify the wording. Another option is that
you'll be able to al= so change wording during AUTH48 (one
of the very last steps of th= e process where the authors go
back and forth with the RFC Editor= to get all the editorial
details right). All that will be requir= ed is for the responsible
AD (in this case Martin Vigoureux) to r= eview the AUTH48
changes and confirm that they are editorial. I w= ould suggest
making small editorial changes now right before we s= end
this off to the RFC Editor.

David

On Wed, Aug 26, 2020 at 5:22 AM Antonin D=C3=A9cimo <antonin.decimo@gmail.com> wrote:
> > 1. Key length=
>
> I disagree. Using 64 octets for SHA-256 gives no additional security.<= br> >
> https://crypto.stackex= change.com/questions/34864/key-size-for-hmac-sha256

Ok, thanks.

> > 2. Digest length
> when a key is configured in a router, it is configured together with > the associated algorithm. The algorithm implies a digest length.

Ah, I see. This is just what I had missed.


Thanks for reviewing my comments. I don=E2=80=99t see any bugs left in the<= br> draft. I=E2=80=99m sorry to see that it=E2=80=99s too late for clarificatio= ns.

-- Antonin

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--00000000000099b5f005adcbb6db-- From nobody Wed Aug 26 15:00:53 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1003A08EE for ; Wed, 26 Aug 2020 15:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiIVpK1KOdxp for ; Wed, 26 Aug 2020 15:00:50 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 2BB7E3A08DB for ; Wed, 26 Aug 2020 15:00:50 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id v6so3756057iow.11 for ; Wed, 26 Aug 2020 15:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ed0mJtno2/i7a5HDZcPiGuZayz+jk5qW4X6V/89a3ss=; b=t5vfyEzcb4b/i+BpozbivTKsbEZDouz/iwTdPDFdrqBMx8YOjax2BE/PQLNio3x9a7 zrT0zlRp0fpCet86MrO5BCDIHl2SoB0z7NW+wzXBPwj8IayosH3L90dr3wHFgpkUWHyu vTrfTn4F47F9xb6kzpj0PbNayhlLYTVGCoTwZQud4SHsIZ057BDUHljkLmCjMJBQv1Lk nz18iupLzgjFk6Sc3wPmf0xVICTBxqWkOPeXtWnrQ5Ld+OUU2Xjtq63wXMNKuJXgtjmm INSi4DsKC2ywlFsk+2ybW1pKVjunyM/sWYGkPeziXGO64rKxPBwpPremXCRzj/AtoHTz vhCg== 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=ed0mJtno2/i7a5HDZcPiGuZayz+jk5qW4X6V/89a3ss=; b=KI9kh1XB66xpb5xKrNKNQBPoHgHEReSEgnxh/Wxj95UasmGZh3usy+EGk+X2N1bHH4 Ig4R7PtmFsF/A0Evxquwo21RQ6S9Zqfh4uhVJj2KXr5BvZHI/v0lOB8Zff+H48pCFpqb t/e5LRh2JY+HvYYdLtlFmLMrpj1gEQQFFepMZThTjL3A0AFQLC5iNQilJgl9FuJy5owz eurqLxCgDObXojEw/zEq0dxqOlWnGdSlCaysKgy2AOZpp9exZog0kCHui7scoIyFQnql v1tONrxfMITaj62xrq+kR0ibPLxessyg2Xh+u5njf8SWi7WHQVD/WrEMOQkuv5elKaH3 41Ew== X-Gm-Message-State: AOAM533PQ70SISGf+mtnjt+1vhd3Vl+2nfneqJVosUZ+sfIR8JQYebRR qnFvRImzntLRfVf9AVq7MMQrgaT+deFrcThUi0M= X-Google-Smtp-Source: ABdhPJx1wJnHQrULqC9KfFGkzjS6FqRZosXrvtd3tifKPbQB/IkfLnVkJ0Q91Fl3/McySvzWR3iLDqMQeayqNc32wow= X-Received: by 2002:a02:9149:: with SMTP id b9mr16593795jag.50.1598479249414; Wed, 26 Aug 2020 15:00:49 -0700 (PDT) MIME-Version: 1.0 References: <87zh6hem9u.wl-jch@irif.fr> In-Reply-To: From: Donald Eastlake Date: Wed, 26 Aug 2020 18:00:38 -0400 Message-ID: To: David Schinazi Cc: =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Babel at IETF , Juliusz Chroboczek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Comments on the MAC authentication for Babel draft X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 22:00:52 -0000 Hi David, On Wed, Aug 26, 2020 at 2:09 PM David Schinazi w= rote: > > To be slightly pedantic about the IETF process here > (chairs, please correct me if I'm wrong), it's not too late > to make editorial changes to the document. It is too > late to make big technical changes, as that would require > the relevant ADs to re-review the document, but as authors > you can feel free to clarify the wording. It's just a little complicated to cover all the paths a draft can take but at this point the draft has been through AD review, IETF Last Call, Directorate Reviews, and IESG balloting. If significant technical changes/extensions are made at this stage, it might require sending the draft back to the WG to go through that process again. However, the draft can simply be cloned under a new file name (like draft-ietf-babel-hmacbis-00 or the like) and the changes made there. Of course, if there is a fatal technical flaw, it is probably the right thing to pull the draft back and have it go through the process again. If it is a bad enough problem, it can even be pulled back from the RFC Editor's queue or at any point until it is actually released as an RFC. (After that, you have to do a new RFC to obsolete it.) > Another option is that > you'll be able to also change wording during AUTH48 (one > of the very last steps of the process where the authors go > back and forth with the RFC Editor to get all the editorial > details right). All that will be required is for the responsible > AD (in this case Martin Vigoureux) to review the AUTH48 > changes and confirm that they are editorial. I would suggest > making small editorial changes now right before we send > this off to the RFC Editor. We can make small editorial/clarification changes at this point. After the RFC Editor gets it, you don't have to wait for AUTH48. The RFC Editor will send out editorial questions and suggestions to the authors along with a request that they review the document and editorial fixes can be resolved then. 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 33896 USA d3e3e3@gmail.com > David > > On Wed, Aug 26, 2020 at 5:22 AM Antonin D=C3=A9cimo wrote: >> >> > > 1. Key length >> > >> > I disagree. Using 64 octets for SHA-256 gives no additional security. >> > >> > https://crypto.stackexchange.com/questions/34864/key-size-for-hmac-sha= 256 >> >> Ok, thanks. >> >> > > 2. Digest length >> > when a key is configured in a router, it is configured together with >> > the associated algorithm. The algorithm implies a digest length. >> >> Ah, I see. This is just what I had missed. >> >> >> Thanks for reviewing my comments. I don=E2=80=99t see any bugs left in t= he >> draft. I=E2=80=99m sorry to see that it=E2=80=99s too late for clarifica= tions. >> >> -- Antonin >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Wed Aug 26 15:01:31 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD3E3A08F4 for ; Wed, 26 Aug 2020 15:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5CK-DJdQa5m for ; Wed, 26 Aug 2020 15:01:27 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 9E0D53A08DB for ; Wed, 26 Aug 2020 15:01:27 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id v6so3757675iow.11 for ; Wed, 26 Aug 2020 15:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M5fqM2xdSL2hg66jFmSWDqZxrSWYf1Og/IyJuDMQUQY=; b=YNTXwiDBqcDP1WoGu6O9/ehw3TCsYR+zxaiU+/tI0b5IdddX6cu5n7zPXJ6ZikLuvM tIRoW0PGH77UgUed06/r1tRuYCOHopIqhbFefsghdsOLV4kXx6KQZaQDuCVYpUZPbnzY zAZIrKBQFOdeLuUTUzbYi1BRkc8vS40OQycXrprGS7VXfHyGne72C8SGunQnPeWizLjG ziUf6T1agfupYKQAKpsOI7WB7+C22xht/68VKdjkF1Mwt36sLV56vbHrq2KR/ICUamOU yiuTGyfQ5x9uLbfYVHLLSgPDdx2n3/V8j0c2udAMCtUkHaZDTda0pf8N+k05Qcpcau7d rFfQ== 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=M5fqM2xdSL2hg66jFmSWDqZxrSWYf1Og/IyJuDMQUQY=; b=CYJ2+k7iaIRpY5twFJaoyaLDxO44HATejBQPbI7uiueYTfA2NSbImNM/8JwDFIJpDk 6hJ4wzDR+SM9fwoBLGhgjDYx3lAdwrwkJaGrqob302meWmQa+r3RCiCSQDO8epoUt+Nt QoKUSOmfjGlc/p0+WQyEpP7ycAL8Ki0aUJmH1v67YPtDfQRbfugLOtpwV3fj9HB5jwlT witYmF2XGQbU5oc6wb3/wOePJux7fbWa4DmMqoDmqVlIWivHDHaBBir//ZjyCZQo7yVg u33Q1gYNVWLXo564/JSMKsOkmzx6Gc3EcYJHjn1u1flN3RIl5FsY27iiYe52DNM4mX/G ZEQQ== X-Gm-Message-State: AOAM533/RPO1p9RcML066AIXVyLGtzfay3TnzaVbqBYXwUy1fYCdwyqN ad51JPr0GwHwW8ukdkCHTANkuaBdN3DR3OqqRHk= X-Google-Smtp-Source: ABdhPJznObZfC0errn6SeeSMqHOtlJBxsuGW4/haTFxGqKout0LG/jRoB4zyK+iuiS/T39mgnyuWnvFtubT1SrtcF9M= X-Received: by 2002:a6b:b513:: with SMTP id e19mr14715102iof.167.1598479286078; Wed, 26 Aug 2020 15:01:26 -0700 (PDT) MIME-Version: 1.0 References: <87zh6hem9u.wl-jch@irif.fr> In-Reply-To: <87zh6hem9u.wl-jch@irif.fr> From: Donald Eastlake Date: Wed, 26 Aug 2020 18:01:14 -0400 Message-ID: To: Juliusz Chroboczek , =?UTF-8?Q?Antonin_D=C3=A9cimo?= Cc: Babel at IETF Content-Type: multipart/alternative; boundary="00000000000007123305adcef65a" Archived-At: Subject: Re: [babel] Comments on the MAC authentication for Babel draft X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 22:01:30 -0000 --00000000000007123305adcef65a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antonin and Juliusz, I'll just reply where I think I can add to Juliusz responses. On Wed, Aug 26, 2020 at 6:26 AM Juliusz Chroboczek wrote: > > Dear Antonin, > > ... > > > 1. Key length > > I disagree. Using 64 octets for SHA-256 gives no additional security. > > https://crypto.stackexchange.com/questions/34864/key-size-for-hmac-sha256 > > > 2. Digest length > > > Reading the length of the MAC TLV in order to compute a MAC of this > > length is not compliant with the protocol (=C2=A74.3) since MACs are > > computed without looking into the packet. > > No. The digest length is part of the algorithm. The algorithm is carrie= d > out-of-band. > > In other words -- when a key is configured in a router, it is configured > together with the associated algorithm. The algorithm implies a digest > length. For example, SHA-256 truncated to 128 bits is a different > algorithm than SHA-256 with full digests. > > I agree that this could be made clearer, but we're not tweaking this at > this stage. I am opposed to the blanket requirement suggested by Antonin as follows: +The length of the MAC MUST be the maximum MAC length computable by +the MAC algorithm (32 octets for both HMAC-SHA256 and keyed +BLAKE2S). Some MAC algorithms may produce very long MACs whose non-truncated use would squeeze out too much useful data. This is a factor in the engineering tradeoff that is being ignored in this suggested change. Truncated MACs are quite common in IETF protocols, although there is usually a floor size below which you are not permitted to go. And there are even arguments that a modest amount of truncation can strengthen a MAC. (Also, from a different point of view, the proposed requirement is trivially evaded because you could just define a new MAC algorithm with the truncation or other condensation of the MAC value from another MAC algorithm and say that this new MAC algorithm is what you are using.) > > 3. Lazy computation > > This is already legal =E2=80=94 your proposed tweak doesn't violate any o= f the > MUST in this paragraph. I agree that your wording is better, but we're > not making this change at this stage. > > > 4. Accepting Challenges > > > When receiving a challenge reply, a node must check if there was a > > challenge in progress before validating the challenge. > > > However the text does not explicitly describe if there are changes > > to be made to the overall state when the challenge succeeds. > > Right. The obvious implementation strategy is to discard the challenge > state after a challenge has succeeded. Not doing that does not cause any > security issues (it's not required by the proof of correctness). > > I think we should add =C2=AB SHOULD discard the state =C2=BB here, but it= requires > Donald's permission. I think adding this "SHOULD" would be too much of a change. In principle it doesn't require my permission, it requires Martin Vigoureux's permission since the draft is out of the WG and in the IESG. Since it doesn't affect correct operation, I would suggest just creating a draft-ietf-babel-hmacbis-00 draft and putting it in that. There seems to be enough WG interest in this that I don't see any need for a formal WG adoption call. 6. Timers > > I was confused at first between the "challenge expiry timer", the two > > rate limits, and the neighbour state expiry timer. I suggest, for > > consistency, the following changes: > > Right. Unfortunately, we're no longer allowed to improve the wording. I don't see any problem with typo fixes and clarifications so the changes in point 6 seem fine to me. > > 5. Replying to challenges > > > Section 4.3.1.2. Replying to challenges, the sentence [...] could be moved > > earlier > > Right again. Not worth fighting for, IMHO. > > > 7. TLV names shouldn't be pluralised > > Same. I think the changes in Section 7 would be OK also. 9. Relations with the Information Model > > The MAC draft defines (amongst other) three optionaly tunable parameters: > [...] > > Should they be reflected in the models? > > No. The protocol is robust enough that the exact values are irrelevant t= o > its security. Prior to writing this message, I reviewed the entire Babel hmac draft and noticed the following: In Section 4.1, the empty box in the IPv4 psuedo-header diagram bothers me. I think it should say the following in that box: Dest address (cont.) for destination address continued. But I'm not sure it is worth fixing these editorial things right now. When the draft is actually processed by the RFC Editor, all the authors will get a message including what editorial problems or ambiguities the RFC Editor thinks they have found along with a request to review the entire draft. At that point any editorial things can be cleared up. 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 33896 USA d3e3e3@gmail.com > -- Juliusz --00000000000007123305adcef65a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antonin and Juliusz,

I'll just reply where I= think I can add to Juliusz responses.

On Wed, Aug 26, 2020 at 6:26 = AM Juliusz Chroboczek <jch@irif.fr>= ; wrote:
>
> Dear Antonin,
>
> ...
>
> = > 1. Key length
>
> I disagree.=C2=A0 Using 64 octets for SH= A-256 gives no additional security.
>
> =C2=A0 https= ://crypto.stackexchange.com/questions/34864/key-size-for-hmac-sha256>
> > 2. Digest length
>
> > Reading the length= of the MAC TLV in order to compute a MAC of this
> > length is no= t compliant with the protocol (=C2=A74.3) since MACs are
> > compu= ted without looking into the packet.
>
> No.=C2=A0 The digest l= ength is part of the algorithm.=C2=A0 The algorithm is carried
> out-= of-band.
>
> In other words -- when a key is configured in a ro= uter, it is configured
> together with the associated algorithm.=C2= =A0 The algorithm implies a digest
> length.=C2=A0 For example, SHA-2= 56 truncated to 128 bits is a different
> algorithm than SHA-256 with= full digests.
>
> I agree that this could be made clearer, but= we're not tweaking this at
> this stage.

I am opposed to = the blanket requirement suggested by Antonin as follows:

+The length= of the MAC MUST be the maximum MAC length computable by
+the MAC algori= thm (32 octets for both HMAC-SHA256 and keyed
+BLAKE2S).

Some MAC= algorithms may produce very long MACs whose non-truncated use would squeez= e out too much useful data. This is a factor in the engineering tradeoff th= at is being ignored in this suggested change. Truncated MACs are quite comm= on in IETF protocols, although there is usually a floor size below which yo= u are not permitted to go. And there are even arguments that a modest amoun= t of truncation can strengthen a MAC. (Also, from a different point of view= , the proposed requirement is trivially evaded because you could just defin= e a new MAC algorithm with the=C2=A0truncation or other condensation of the= MAC value from another MAC algorithm and say that this new MAC algorithm i= s what you are using.)

> > 3. Lazy computation
>
>= This is already legal =E2=80=94 your proposed tweak doesn't violate an= y of the
> MUST in this paragraph.=C2=A0 I agree that your wording is= better, but we're
> not making this change at this stage.
>= ;
> > 4. Accepting Challenges
>
> > When receiving = a challenge reply, a node must check if there was a
> > challenge = in progress before validating the challenge.
>
> > However t= he text does not explicitly describe if there are changes
> > to b= e made to the overall state when the challenge succeeds.
>
> Ri= ght.=C2=A0 The obvious implementation strategy is to discard the challenge<= br>> state after a challenge has succeeded.=C2=A0 Not doing that does no= t cause any
> security issues (it's not required by the proof of = correctness).
>
> I think we should add =C2=AB SHOULD discard t= he state =C2=BB here, but it requires
> Donald's permission.
<= br>I think adding this "SHOULD" would be too much of a change. In= principle it doesn't require my permission, it requires Martin=C2=A0Vi= goureux's=C2=A0permission since the draft is out of the WG and in the I= ESG.

Since it doesn't affect correct operation, I wo= uld suggest just creating a draft-ietf-babel-hmacbis-00 draft and putting i= t in that. There seems to be enough WG interest in this that I don't se= e any need for a formal WG adoption call.

6. Timers

> >= ; I was confused at first between the "challenge expiry timer", t= he two
> > rate limits, and the neighbour state expiry timer. I su= ggest, for
> > consistency, the following changes:
>
>= Right.=C2=A0 Unfortunately, we're no longer allowed to improve the wor= ding.

I don't see any problem with typo fixes and clarifications= so the changes in point 6 seem fine to me.

> > 5. Replying to= challenges
>
> > Section 4.3.1.2. Replying to challenges, t= he sentence [...] could be moved
> > earlier
>
> Right= again.=C2=A0 Not worth fighting for, IMHO.
>
> > 7. TLV nam= es shouldn't be pluralised
>
> Same.

I think the cha= nges in Section 7 would be OK also.

9. Relations with the Informatio= n Model

> > The MAC draft defines (amongst other) three o= ptionaly tunable parameters:
> [...]
> > Should they be refl= ected in the models?
>
> No.=C2=A0 The protocol is robust enoug= h that the exact values are irrelevant to
> its security.

Prio= r to writing this message, I reviewed the entire Babel hmac draft and notic= ed the following: In Section 4.1, the empty box in the IPv4 psuedo-header= =C2=A0diagram bothers me. I think it should say the following in that box:<= /div>

Dest address (cont.)

fo= r destination address continued.

But I'm not s= ure it is worth fixing these editorial things right now. When the draft is = actually processed by the RFC Editor, all the authors will get a message in= cluding what editorial problems or ambiguities the RFC Editor thinks they h= ave found along with a request to review the entire draft. At that point an= y editorial things can be cleared up.

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
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)<= br>=C2=A02386 Panoramic Circle, Apopka, FL 33896 USA
=C2=A0d3e3e3@gmail.com

> -- Juliu= sz

--00000000000007123305adcef65a-- From nobody Thu Aug 27 05:58:51 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201543A0774 for ; Thu, 27 Aug 2020 05:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNfe8NM-FrCk for ; Thu, 27 Aug 2020 05:58:48 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B56A3A0812 for ; Thu, 27 Aug 2020 05:58:47 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 07RCwjfV002102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Aug 2020 14:58:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 07RCwjkt011519; Thu, 27 Aug 2020 14:58:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id BE263C7307; Thu, 27 Aug 2020 14:58:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id XvaP51RkXahP; Thu, 27 Aug 2020 14:58:44 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 74DFCC7305; Thu, 27 Aug 2020 14:58:43 +0200 (CEST) Date: Thu, 27 Aug 2020 14:58:42 +0200 Message-ID: <873648meil.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Antonin =?ISO-8859-1?Q?D=E9cimo?= , Babel at IETF In-Reply-To: References: <87zh6hem9u.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 27 Aug 2020 14:58:45 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 27 Aug 2020 14:58:45 +0200 (CEST) X-Miltered: at korolev with ID 5F47AE05.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F47AE05.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F47AE05.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F47AE05.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 : 5F47AE05.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F47AE05.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] Comments on the MAC authentication for Babel draft X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 12:58:50 -0000 >>> 4. Accepting Challenges >> >>> When receiving a challenge reply, a node must check if there was a >>> challenge in progress before validating the challenge. >> >>> However the text does not explicitly describe if there are changes >>> to be made to the overall state when the challenge succeeds. >> Right. The obvious implementation strategy is to discard the challenge >> state after a challenge has succeeded. Not doing that does not cause any >> security issues (it's not required by the proof of correctness). >> >> I think we should add « SHOULD discard the state » here, but it requires >> Donald's permission. > I think adding this "SHOULD" would be too much of a change. In principle it > doesn't require my permission, it requires Martin Vigoureux's permission since > the draft is out of the WG and in the IESG. Shall I ask Martin? > Since it doesn't affect correct operation, I would suggest just creating a > draft-ietf-babel-hmacbis-00 draft and putting it in that. I'm not volunteering. -- Juliusz From nobody Thu Aug 27 06:14:03 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EBD3A085A for ; Thu, 27 Aug 2020 06:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qgo5nPFzz5Q for ; Thu, 27 Aug 2020 06:14:00 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8369E3A0855 for ; Thu, 27 Aug 2020 06:14:00 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 07RDDwBr010262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Aug 2020 15:13:58 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 07RDDwCp017695; Thu, 27 Aug 2020 15:13:58 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5C95BC7545; Thu, 27 Aug 2020 15:13:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id s2FhuBuDt8yO; Thu, 27 Aug 2020 15:13:57 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CEE60C7542; Thu, 27 Aug 2020 15:13:56 +0200 (CEST) Date: Thu, 27 Aug 2020 15:13:56 +0200 Message-ID: <871rjsmdt7.wl-jch@irif.fr> From: Juliusz Chroboczek To: Antonin =?ISO-8859-1?Q?D=E9cimo?= Cc: Babel at IETF , babel-users 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=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 27 Aug 2020 15:13:58 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 27 Aug 2020 15:13:58 +0200 (CEST) X-Miltered: at korolev with ID 5F47B196.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F47B196.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F47B196.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F47B196.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 : 5F47B196.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F47B196.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] MAC auth. for Babel in babeld X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 27 Aug 2020 13:14:03 -0000 > I’ve rolled up my sleeves and finished my implementation of the MAC > authentication protocol in babeld. Excellent! I'll get to work on reviewing that as soon as teaching is under control. (In case anyone is interested -- we've got a lot of COVID-related restrictions, which I happen to support, but we're getting very little help with implementing them. I'm down to buying my own masks to distribute to students who forget theirs.) > There is one feature that I have not implemented (yet): expiring > per-neighbour state (section 4.4) using the Hello history or a timer > based on the last accepted packet. Yes, you have :-) The per-neighbour state is attached to the neighbour entry, and the neighbour entry will be discarded soon after the hello history becomes empty. See the function check_neighbours in neighbour.c, which is called periodically by the main loop. > The code has not undergone review. No interoperability testing has > been done. Please find out if you're allowed to enter the office (not obvious due to COVID). If not, I'll ask the boss for permission, or else we'll meet at my place. > I’m also looking for feedback on the user interface. [...] In > particular, do you think that implementing keysets and allowing an > unbounded number of keys is too much for babeld? As a general rule, I'm in favour of reflecting the implementation details in the user interface to the extent possible -- if you don't do that, the interface becomes confusing to the user who cannot build an accurate mental model of what's going on. If that's too complicated, I'd rather we add some macros than dumb down the interface. (Commands that expand to a sequence of lower-level commands.) You should consider what happens to your code when there are too many keys, and the MACs no longer fit in a packet. A silent failure would be bad. -- Juliusz From nobody Thu Aug 27 06:16:40 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D603A086D for ; Thu, 27 Aug 2020 06:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WB5SroCaOSy for ; Thu, 27 Aug 2020 06:16:34 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6D23A0891 for ; Thu, 27 Aug 2020 06:16:33 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 07RDGVLF011404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Aug 2020 15:16:31 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 07RDGVfC018560; Thu, 27 Aug 2020 15:16:31 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2382FC75CE; Thu, 27 Aug 2020 15:16:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id R3N0io9ZPYb6; Thu, 27 Aug 2020 15:16:29 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C431CC75CC; Thu, 27 Aug 2020 15:16:29 +0200 (CEST) Date: Thu, 27 Aug 2020 15:16:29 +0200 Message-ID: <87y2m0kz4i.wl-jch@irif.fr> From: Juliusz Chroboczek To: Antonin =?ISO-8859-1?Q?D=E9cimo?= Cc: babel-users , Babel at IETF In-Reply-To: <871rjsmdt7.wl-jch@irif.fr> References: <871rjsmdt7.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 27 Aug 2020 15:16:31 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 27 Aug 2020 15:16:31 +0200 (CEST) X-Miltered: at korolev with ID 5F47B22F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F47B22F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F47B22F.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F47B22F.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 : 5F47B22F.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F47B22F.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] MAC auth. for Babel in babeld X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 27 Aug 2020 13:16:36 -0000 >> I’ve rolled up my sleeves and finished my implementation of the MAC >> authentication protocol in babeld. Did I say thanks? I think I didn't say thanks. Thanks, Antonin. -- Juliusz From nobody Thu Aug 27 13:41:31 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD0F3A12DF for ; Thu, 27 Aug 2020 13:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sZryQ2S0l0p for ; Thu, 27 Aug 2020 13:41:29 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12D53A12E0 for ; Thu, 27 Aug 2020 13:41:28 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id q14so6038464ilj.8 for ; Thu, 27 Aug 2020 13:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hYk6yLRyOmQyDI3VXGyDW57BqV+EFSAvzoaqSz/c6Fc=; b=c/2p3Ek/kMqv5v8y5NmeA2c+pICnzMCGsEj9Gdaoicpu3WC/22rcS0wbBANjmX+jeY qQqNBuePFyKufP932SYiYQjPvyT8BZLw07SaHJVkwodYrYu3BevcSqqdciIzXE4eGNkI 3Pxa8oM8BLtN/NdTeiFMDsFrJLjuIoB+ztqNbmzOnhWlg2QeuNgs5aVnWX6rQ0yy9RwM gIxIyuVK1/60uRy4tk/enYL08vYAKB4YCnP3I5hJCSXLL30LrtPq2+xh3RpE6Y5I+Nbq 8g/A04GaPZq43UPuprM+T4nYsuwmebFssaglcrxhVEsRjh6rv2kGZ2SPSese6XLSBpw/ OmCQ== 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=hYk6yLRyOmQyDI3VXGyDW57BqV+EFSAvzoaqSz/c6Fc=; b=Eai3j3s4oJrfWLhongBXOm6qFDeOZ3n4U4hzwXJzqQzzlSud4GlOlB8R4ooR6sBnqP 8fxYDn3VQ/ST7IkiAGmJjj2vzYJnn6h+vUbTejC50vI4bg4Tqrdp+iTdWa67g86GQ+T+ xxhQoTshbo67fzDxPaudzAWysor2S54b94P1yMZX+j5ia/GKargnHwNjHZrqEwbysgHa ibJrFJsSU9+RuHFjA7uxhWhSL+p/L3+9d19n/LuvDzVwi1i/aUugqY2wwUL73ul8d8tV Pxoky/JGwr5e30yyz8TGLukE9A71+SesDHhGqEAeL86eoAbNRfrAp66N1QDqPSkIJcGM YNWw== X-Gm-Message-State: AOAM53298Z7wmWWMaMKG3di0ESn+htWBaDMCY1ByjX0PUZzOLNNi2Xmt 8W3usmQ2dNT98fWIGGNRLMgppXLUd35Z2WsNvyvDrL/XBig= X-Google-Smtp-Source: ABdhPJxjzVZPtHKTMwcMW2EBGT4EgXNZcy1S0/8zIAzDd8bQIuF+wTqC0lYQFxqToM8HI5QfPL9f6BDDK9XAvza84YE= X-Received: by 2002:a05:6e02:12a3:: with SMTP id f3mr19686634ilr.83.1598560888210; Thu, 27 Aug 2020 13:41:28 -0700 (PDT) MIME-Version: 1.0 References: <87zh6hem9u.wl-jch@irif.fr> <873648meil.wl-jch@irif.fr> In-Reply-To: <873648meil.wl-jch@irif.fr> From: Donald Eastlake Date: Thu, 27 Aug 2020 16:41:17 -0400 Message-ID: To: Juliusz Chroboczek Cc: =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Comments on the MAC authentication for Babel draft X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 20:41:30 -0000 Hi Juliusz, On Thu, Aug 27, 2020 at 8:58 AM Juliusz Chroboczek wrote: > > >>> 4. Accepting Challenges > >> > >>> When receiving a challenge reply, a node must check if there was a > >>> challenge in progress before validating the challenge. > >> > >>> However the text does not explicitly describe if there are changes > >>> to be made to the overall state when the challenge succeeds. > > >> Right. The obvious implementation strategy is to discard the challeng= e > >> state after a challenge has succeeded. Not doing that does not cause = any > >> security issues (it's not required by the proof of correctness). > >> > >> I think we should add =C2=AB SHOULD discard the state =C2=BB here, but= it requires > >> Donald's permission. > > > I think adding this "SHOULD" would be too much of a change. In principl= e it > > doesn't require my permission, it requires Martin Vigoureux's permissio= n since > > the draft is out of the WG and in the IESG. > > Shall I ask Martin? You are welcome to do so if you want. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > > Since it doesn't affect correct operation, I would suggest just creatin= g a > > draft-ietf-babel-hmacbis-00 draft and putting it in that. > > I'm not volunteering. > > -- Juliusz From nobody Fri Aug 28 15:46:22 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D293A0D5F for ; Fri, 28 Aug 2020 15:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDiq5VVcRjT7 for ; Fri, 28 Aug 2020 15:46:19 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76CF33A07F2 for ; Fri, 28 Aug 2020 15:46:19 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id c18so524020wrm.9 for ; Fri, 28 Aug 2020 15:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:cc:subject:from:to:date :message-id:in-reply-to; bh=S1V7jGbjF83H5CY+JDzne9GEZ1gqYkgPwcntNPlXK14=; b=MFqJjhrodgPoPKSku4OQX8IcWNWCPtF7tUDf3bkiByII7AuHmvb7rJT9ym0+KHNQWM TC/O4IqhIEVogd2bu0XDki3BgrqhBzui2Uy3v2ds/TuQ0sbLaztMWpbkioBMd6UWDpeC 2s0tAnICUHNG5lX4reKka8r4vhlXnNV303WjDWP7pgRGMwrqIe8pcPKHEOKE6ggCMjZW DdVCReK3fYuPQtVXUTqS9xB7qFKZpg/y6TBw7HVYVzNSMAZ3oa0IuO7eLEbjRhUXApui ukawe0QAMaert5tgqK0ADHoZek53Mjfypvxk9LiId3WGhDN7EWYesiUvp6vBeJoOVPbs RjpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding:cc :subject:from:to:date:message-id:in-reply-to; bh=S1V7jGbjF83H5CY+JDzne9GEZ1gqYkgPwcntNPlXK14=; b=KLPcs069gWcV58nzPcM/6p0XepPKPZfJc/Dem4cwrE4pKgJuaHkPqHlyRZa9jbCnod ngVUBKANJUOhZJzS0qVX1lwsj35J8Jv/GHPqC783/qhCkS0SR4zESlTJz397GBMDsmGG QwGLIpO/wBDR1iUupDFuGSfIYzX1O/6pIZqHh2L72uCgBpDroJTxGuPYSMiXe1xn27US M67PvwZ10FrsNwoHabOgyKu32BGJ9LSooSSP1UZSVVO28eLxMr/7042zXkZVnyvLXRxE KkeBEsaObzdNlovNZmCtszm8kgsYZMYBGbdakpJ/oFpXmOYfMDnfPZlX8tk1Kadn1IwX tf+Q== X-Gm-Message-State: AOAM530/5mR4AHMU554R6Rk8a+/RH36RUPOOBi0c2dXHERKXmo3FCyZT p4gw2L78GuvoqeOSTF4WYzo= X-Google-Smtp-Source: ABdhPJxhIJcKPVbd5sBUwZl7EUzyw/D5wDx97/cje8XNt4fNSy754pv2H7OdSBtI12+Dr/z0hEYS+g== X-Received: by 2002:adf:a3c9:: with SMTP id m9mr1014448wrb.80.1598654777870; Fri, 28 Aug 2020 15:46:17 -0700 (PDT) Received: from localhost (176-190-174-144.abo.bbox.fr. [176.190.174.144]) by smtp.gmail.com with ESMTPSA id x2sm1280601wrg.73.2020.08.28.15.46.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Aug 2020 15:46:17 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Cc: "Babel at IETF" , "babel-users" From: =?utf-8?q?Antonin_D=C3=A9cimo?= To: "Juliusz Chroboczek" Date: Fri, 28 Aug 2020 22:41:11 +0200 Message-Id: In-Reply-To: <871rjsmdt7.wl-jch@irif.fr> Archived-At: Subject: Re: [babel] MAC auth. for Babel in babeld X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 22:46:21 -0000 Another thing that could be added: a separate table for uncompleted challenges (see en paragraph of section 7). > > There is one feature that I have not implemented (yet): expiring > > per-neighbour state (section 4.4) using the Hello history or a timer > > based on the last accepted packet. > > Yes, you have :-) Well that=E2=80=99s a relief! > Please find out if you're allowed to enter the office (not obvious > due to COVID). If not, I'll ask the boss for permission, or else > we'll meet at my place. You=E2=80=99ll have to invite me to allow me to enter the premises =F0=9F= =A7=9B > > I=E2=80=99m also looking for feedback on the user interface. [...] In > > particular, do you think that implementing keysets and allowing an > > unbounded number of keys is too much for babeld? > > As a general rule, I'm in favour of reflecting the implementation > details in the user interface to the extent possible -- if you don't > do that, the interface becomes confusing to the user who cannot > build an accurate mental model of what's going on. After some failed attemps, I had started the other way around and designed the most complete user interfacte I could think of, and then build the implementation to match that model. > If that's too complicated, I'd rather we add some macros than dumb > down the interface. (Commands that expand to a sequence of > lower-level commands.) Hmm, nice idea. We could have a single keyset of two key slots, shared by all interfaces, with the simplest user interface. We can have a pre-configured timer for key rotation during which both keys would be available. interface default mac true rotate-key hmac-sha256 0000 =E2=80=A6 rotate-key hmac-sha256 1111 It=E2=80=99s not clear right now how the 'complete' and the 'simple' interf= ace could be used in the same time, but that is absolutely workable. > You should consider what happens to your code when there are too many > keys, and the MACs no longer fit in a packet. A silent failure would be > bad. The packet is not send. There are two error messages. The buffer is discarded. -- Antonin From nobody Sat Aug 29 21:39:22 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCFC3A0F44; Sat, 29 Aug 2020 21:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_wDLqOTuxGn; Sat, 29 Aug 2020 21:39:19 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-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 1B2233A08AF; Sat, 29 Aug 2020 21:39:19 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id p13so1179670ils.3; Sat, 29 Aug 2020 21:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=btFKMs5Bvq6DzAby/xFx8jZ34s+6evqyqWDsTfjNv8E=; b=Uuy9da0wSv8oonVZqEDpTS0L6jK1Mb3E749BS/eQC8dKg6Mjg8xSWU65gThIUXPemO 0RTcmrZzBKYNcvLRxnQYIEF6wHeGBTbjmVbDGuEN601sLpnGujLS+h6bMpQH6fFyikNQ irZgCBMgKioD4XaHgck8BiMltr2HCXwJG2MXZX0HMj6RRuI2z1XiuOeFXQCR56ABuDs5 NcD0ObZH6ScQWaX/Jq+91UVSc+aY1pNFXWwYkKwsoFwxzGAiQXe40wmR9L1iElkGuPOq aXnz+eOauXBNoDWEbgO01xJZ4eQy3tTvhwa5L8HkwyHhlB5ITPPy7aPmD43wDVZCrxr9 tURw== 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=btFKMs5Bvq6DzAby/xFx8jZ34s+6evqyqWDsTfjNv8E=; b=fc7RDuKqBDIcBHwKIE6kT02CLeI6XjmOJV4Zk953umopq6WIGzydZ62xiHcwGaY8hP AcTxEskwp/2NCh5vy4pSzLDNjh/qGQovuNgViShV3ChPoy+9bwpdhEBJc3knEAOZaseC iZUUkAkG6nf/Voam6QENAKV5jFGkjdg+p2Vx0POL8mFIloTxkG0hzXGEjUHfaiq0vAI6 K2ZtYFkGCVzRQxYpz+4/wT7rasOp2DeO24TXFQtEQ4Jh8wPtjTUAHy87MXZPbG9bKwCD Dtngpajvk8H4nnDeMH1ZIi52WiB20VQmejRoadNSsBQ0ehySQxwid12FzMHpsFiWR6Pa esFw== X-Gm-Message-State: AOAM530HzRhz4JZ6N7jicZ59lm3IOcLdcsKHPNuD70adA/wQdDxLG57D XwX5QJ1dqqsL+wmEWXCEE6vR8Pt/L1q61PXmskbFQzzeYIU= X-Google-Smtp-Source: ABdhPJyF8nK74VxxzkWMQGBEZRlE2uRXMZlJ3aisnSr+ak0/S+X5pIahebdq/cjlRc/QS5/aT6/z+5/bZyIs9waSjiI= X-Received: by 2002:a92:189:: with SMTP id 131mr4877572ilb.40.1598762358051; Sat, 29 Aug 2020 21:39:18 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Sun, 30 Aug 2020 00:39:07 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] WG Last Call through September 14th for draft-ietf-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: Sun, 30 Aug 2020 04:39:22 -0000 Hi, The Yang model draft (version -04) did actually pass WG last call before but shortly there after some questions arose. There were changes of some significance between -04 and -05 (see https://tools.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-05.txt) but very minor changes between -05 and the current -06 (I believe just some formatting and author info changes). So, as announced at the July Babel WG meeting, this is a WG Last Call through September 14 for moving forward with this draft and requesting RFC publication. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com ---------- Forwarded message --------- From: Date: Sun, Jun 28, 2020 at 5:18 PM Subject: [babel] I-D Action: draft-ietf-babel-yang-model-06.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : YANG Data Model for Babel Authors : Mahesh Jethanandani Barbara Stark Filename : draft-ietf-babel-yang-model-06.txt Pages : 38 Date : 2020-06-28 Abstract: This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-yang-model-06 https://datatracker.ietf.org/doc/html/draft-ietf-babel-yang-model-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ babel mailing list babel@ietf.org https://www.ietf.org/mailman/listinfo/babel From nobody Mon Aug 31 11:24:42 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53FE3A1871; Mon, 31 Aug 2020 11:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Qj_OcSpo-pt; Mon, 31 Aug 2020 11:24:39 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C203A186F; Mon, 31 Aug 2020 11:24:38 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id y4so6763365ljk.8; Mon, 31 Aug 2020 11:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j3rx2rnc2gFxxB+iEqixIUAsFoQ/mqBhYJyVzClvWbo=; b=j8PaDgx1P2YrSKoa2J0PXo3G9b1McvuJ2Wa4iOZYkDApAfybYlTj8C8UhhvJZM68m+ bumrEMtE3kYQUrjBNvpG001CpLmrWQB4hVsxyThi4pCMpzFoIGk7ti/OsodF/ssalE+9 QVrdCHnRwC8IuXPd35bYue9a6+kxvPwx50I3S7UOxBSOmRhzhmau+N7G5Jk6oTQD5Nnj Lb4IgZmvhi4xNZAai0EvUt9J4Ff4SRHPC8sFQc6oZtWUqze+T3ChMhLp3e5RncbNWBY0 bXrW/f/mRyjTykk0PfWu7gY9LntoylCzFFnA+7xH0YNLukzJYCE+Ge2kRNiUflJ1xawf t2aw== 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=j3rx2rnc2gFxxB+iEqixIUAsFoQ/mqBhYJyVzClvWbo=; b=sElw3vNH2KT6HOQUXgBUBfnJF9mQt8BipJVr93+5iWaKfiLxmKF8uQSywbmdAhhL/M Cul+6zAQfXMSagAenKBkuMPmT6gRwu2ANDmG6N+tRfCfWVjsQMWsMWU7U9AwhHBfa1F5 TID0s3tMyv/POjQDfN0XnJPgLfunIt92Vfx+IWYC+k5d1uckcjwpl+UkjpZn/EbnZWwo zSgcWoPa/9AR9l+Ucgau9wOSFYKOoWEmRlS0YnM8nYudbHm0he0RoEkO4p5LJ+SqONVP GWby/jw6CW0Lqv9Sg6R/fdWfmOy0ss8EjftZa9xfYjq8+dq7V9JVnx57ArM3MP3YmU1f ntjQ== X-Gm-Message-State: AOAM531no2sWk2aBTQ+uM4Fe0t7w+pwqeP0yxbSQMIIdQWm7e5/zIF5r AKVhcyUP67I5ZshtgLx2U1xcc41ZTYSPX1YBooA= X-Google-Smtp-Source: ABdhPJyCliaDbEau9Rs3OP5byJl1vVOQmISQfGMeQeWCzlAOKqUphg8Xqmthx9M3Pjf/hzLtzO96t3yfm4gKN4xqrA4= X-Received: by 2002:a2e:3615:: with SMTP id d21mr1226605lja.333.1598898276959; Mon, 31 Aug 2020 11:24:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Mon, 31 Aug 2020 11:24:25 -0700 Message-ID: To: Donald Eastlake Cc: Babel at IETF , babel-chairs Content-Type: multipart/alternative; boundary="000000000000d48d7505ae308362" Archived-At: Subject: Re: [babel] WG Last Call through September 14th for draft-ietf-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: Mon, 31 Aug 2020 18:24:41 -0000 --000000000000d48d7505ae308362 Content-Type: text/plain; charset="UTF-8" I reviewed the diff from -04 to -06 and I believe this document is ready for publication. Cheers, David On Sat, Aug 29, 2020 at 9:39 PM Donald Eastlake wrote: > Hi, > > The Yang model draft (version -04) did actually pass WG last call > before but shortly there after some questions arose. There were > changes of some significance between -04 and -05 (see > https://tools.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-05.txt) > but very minor changes between -05 and the current -06 (I believe just > some formatting and author info changes). > > So, as announced at the July Babel WG meeting, this is a WG Last Call > through September 14 for moving forward with this draft and requesting > RFC publication. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > ---------- Forwarded message --------- > From: > Date: Sun, Jun 28, 2020 at 5:18 PM > Subject: [babel] I-D Action: draft-ietf-babel-yang-model-06.txt > To: > Cc: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Babel routing protocol WG of the IETF. > > Title : YANG Data Model for Babel > Authors : Mahesh Jethanandani > Barbara Stark > Filename : draft-ietf-babel-yang-model-06.txt > Pages : 38 > Date : 2020-06-28 > > Abstract: > This document defines a data model for the Babel routing protocol. > The data model is defined using the YANG data modeling language. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-babel-yang-model-06 > https://datatracker.ietf.org/doc/html/draft-ietf-babel-yang-model-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000d48d7505ae308362 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I reviewed the diff from -04 to -06 and I believe=C2=A0thi= s document is ready=C2=A0for publication.

Cheers,
<= div>David

On Sat, Aug 29, 2020 at 9:39 PM Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi,

The Yang model draft (version -04) did actually pass WG last call
before but shortly there after some questions arose. There were
changes of some significance between -04 and -05 (see
https://tools.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-babel-yang-model-05.txt)
but very minor changes between -05 and the current -06 (I believe just
some formatting and author info changes).

So, as announced at the July Babel WG meeting, this is a WG Last Call
through September 14 for moving forward with this draft and requesting
RFC publication.

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 =C2=A0+1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.co= m


---------- Forwarded message ---------
From: <int= ernet-drafts@ietf.org>
Date: Sun, Jun 28, 2020 at 5:18 PM
Subject: [babel] I-D Action: draft-ietf-babel-yang-model-06.txt
To: <i-d-anno= unce@ietf.org>
Cc: <babel@ietf.org<= /a>>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Babel routing protocol WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= YANG Data Model for Babel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mahe= sh Jethanandani
=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 Barbara Stark
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-babel-yang-model-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 38
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-06-28

Abstract:
=C2=A0 =C2=A0This document defines a data model for the Babel routing proto= col.
=C2=A0 =C2=A0The data model is defined using the YANG data modeling languag= e.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= ietf-babel-yang-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ba= bel-yang-model-06
https://datatracker.ietf.org/doc= /html/draft-ietf-babel-yang-model-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-babel-yang-model-06


Please note that it may take a couple of minutes from the time of submissio= n
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/


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

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