From nobody Wed Nov 1 09:35:09 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA14A13F792 for ; Wed, 1 Nov 2017 09:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO3SE-Zq3RPj for ; Wed, 1 Nov 2017 09:35:07 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C8C13F758 for ; Wed, 1 Nov 2017 09:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1509554104; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=3651; bh=qb6Nr6QP0YeXahTmSv9S60TVXCuoRP6c4uQAoIhiwjw=; b=MqooRW1gU7zahsj0mjLP2d3QdJhy3J6ThUmb4yj/18EnhAnOeVmTGDf+Qn9E2OPk NhtQZ8lUJSDDqlph35AfPk/P19A9BMuphSVf/30/F6FuOUOUzGySx2W76yP0H5mq2s5 Kj5BRC9VYjPiWNBJdxNw8qWX/90Td4zGbOi3NvwU= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1509554104053136.35838772269312; Wed, 1 Nov 2017 09:35:04 -0700 (PDT) Date: Wed, 01 Nov 2017 16:35:04 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> In-Reply-To: <87inevut4p.fsf@toke.dk> References: <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 01 Nov 2017 16:35:08 -0000 ---- On Tue, 31 Oct 2017 17:25:26 +0000 Toke H=C3=B8iland-J=C3=B8rgensen wrote ----=20 > Denis Ovsienko writes:=20 > =20 > > > I'm terribly sorry if I'm being obtuse here, but from this comment = it =20 > > > seems to me that your objection is specifically to the use of the t= erm =20 > > > 'bidirectional reachability', because you read that to imply someth= ing =20 > > > stronger than what Babel does? =20 > > > =20 > > > If so, what term would you suggest to use instead? Or would it suff= ice =20 > > > to explicitly spell out that this is a weaker property than in some= =20 > > > other places (which?)? =20 > >=20 > > No problem, let me explain one more time.=20 > >=20 > > The way Babel is currently specified allows a protocol instance think= =20 > > it has a 2-way exchange with a neighbour, whereas in reality it can be= =20 > > just fed with replayed old packets. That's the way the protocol is=20 > > literally specified, no matter what was originally meant and what=20 > > comments were made on the mailing list or in person.=20 > >=20 > > The way it is commonly specified for other protocols involves a nonce= =20 > > or another proof of freshness. For example, completing a 3-way TCP=20 > > handshake on behalf of a random remote host is impossible with just=20 > > replayed packets. TCP-based protocols rely on this property; non-TCP= =20 > > protocols have to implement this property themselves: DD sequence=20 > > numbers in OSPF, nonces in IKE, MPTCP, IPv6 mobility and even almost= =20 > > (but not really, because the nonce is not in the right TLV type)=20 > > Babel. There are examples in many other protocol designs as this is=20 > > quite an old problem.=20 > =20 > Yeah, this is what I meant: You're saying that "bidirectional=20 > reachability" has a specific, well-defined and ubiquitous meaning which= =20 > implies certain security properties (such as replay protection).=20 > =20 > However, prior to you brining it up, I have not been aware of any such= =20 > well-defined meaning of the term. For TCP, for instance, it's called the= =20 > "3-way handshake". So I would agree with you that if the term used was= =20 > "handshake", your point stands. But simply using "bidirectional=20 > reachability" in the informal way it is used in the Babel spec does not= =20 > imply such a specific term to me. So I would ask you to point me any=20 > definitions that include this implication of the wording currently in=20 > the Babel spec?=20 3.4. Neighbour Acquisition Neighbour acquisition is the process by which a Babel node discovers the set of neighbours heard over each of its interfaces and ascertains bidirectional reachability. On unreliable media, neighbour acquisition additionally provides some statistics that may be useful for link quality computation. The text says "ascertains bidirectional reachability" and in the network pr= otocols language this is a statement with a meaning. Then Section 3.4.2 fur= ther elaborates on how this is done and it takes to stare at the TLV diagra= ms for quite a while to realize the actual behaviour is different. If the protocol does not deliver this property either the text or the proto= col need to be fixed. What actually is in the box must be what is says on t= he box. > -Toke=20 > =20 > P.S., as I said, I'm fine with adding a note to, say, section 3.4.2 that= =20 > makes it clear that the protocol does *not* have this stronger property.= =20 Yes, exactly. --=20 Denis Ovsienko From nobody Wed Nov 1 09:42:57 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EEA13F7E5 for ; Wed, 1 Nov 2017 09:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ7G5VVJeVSy for ; Wed, 1 Nov 2017 09:42:47 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B0A13F7CD for ; Wed, 1 Nov 2017 09:42:46 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1509554559; bh=p3G0riggfzaPNryojOC5nW+XAP3zBjvl+P9C2vLtMIE=; h=From:To:Subject:In-Reply-To:References:Date:From; b=WUnSplM0jakAbisspF/6WgdV8DI8mZBcNbBH//FElVyYAzV3ZdzRhfi/M8bQbmJb/ ccnfKhb1WdNJWv9eJAhk6i8P05HYztCCziu1L5JdXXbc9dJZ11e1q/HrVsPJEekWR7 38WTKcpHSfRKPTyMgXiLG9QfkKt/1Qf2kPzCO6tfgx6N3UE+4JsNh7Xs7I3mb9x9w6 K4jdEQTdJiX+9D5uq8Z+1XxPz4QCt/qLlZZck4xwIfVbTSjsYvQIPyS2IqDrFrYBz7 Lfc5swC6otvP9SOf+kSo3Ezy5AVFm4XHArEsziNLB5SruS3ixGWVsBURML1BXdbZos yfwyqOOp0iE0Q== To: Denis Ovsienko , Babel at IETF In-Reply-To: <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> References: <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> Date: Wed, 01 Nov 2017 17:42:37 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r2tikl1e.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 01 Nov 2017 16:42:49 -0000 Hi Denis I think this is the critical point: > The text says "ascertains bidirectional reachability" and in the > network protocols language this is a statement with a meaning. Which "network protocols language" are you referring to? As I said, I did not get the same specific meaning out of Section 3.4 when I first read it; and I have not been able to find a definition of this term anywhere through my (admittedly limited) googling. So if you could provide a reference, that would be helpful :) -Toke From nobody Thu Nov 2 15:38:29 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD62713F6AC for ; Thu, 2 Nov 2017 15:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 n8nk1TZr-KS0 for ; Thu, 2 Nov 2017 15:38:27 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0814813F6A5 for ; Thu, 2 Nov 2017 15:38:27 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 2D1AD26D2A for ; Thu, 2 Nov 2017 15:38:08 -0700 (PDT) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by c8a.amsl.com (Postfix) with ESMTPSA id 0B7AE26CBB for ; Thu, 2 Nov 2017 15:38:08 -0700 (PDT) Received: by mail-io0-f182.google.com with SMTP id n137so2417556iod.6 for ; Thu, 02 Nov 2017 15:38:26 -0700 (PDT) X-Gm-Message-State: AMCzsaXaPLVD3Re5wjcIHru52WWV/r+yy7TuxrQoBjKTge0lSfWRCBGP fRMzS20ZNirIfdpxfQ6yOoSI3Sv8ONLcudnWbAw= X-Google-Smtp-Source: ABhQp+RrqjODdoEJ+e84T6aH9BTRix7Wf6QGXQlVgb47/U/+it2ub9NDdSyhXY9mivMo6U5PeGKlJM+di9c+Eg5I2Ks= X-Received: by 10.36.54.195 with SMTP id l186mr4660596itl.37.1509662306354; Thu, 02 Nov 2017 15:38:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.73.88 with HTTP; Thu, 2 Nov 2017 15:38:05 -0700 (PDT) From: Glen Date: Thu, 2 Nov 2017 15:38:05 -0700 X-Gmail-Original-Message-ID: Message-ID: To: babel@ietf.org Content-Type: multipart/alternative; boundary="001a114419b0804ae7055d07a51e" Archived-At: Subject: [babel] Test, please ignore X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Nov 2017 22:38:28 -0000 --001a114419b0804ae7055d07a51e Content-Type: text/plain; charset="UTF-8" Apologies for the noise. We are investigating complaints of posting errors to this list. Glen -- Glen Barney IT Director AMS (IETF Secretariat) --001a114419b0804ae7055d07a51e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for the noise.=C2=A0 We= are investigating complaints of posting errors to this list.

= Glen
--
Glen Barney
IT Director
AMS (IE= TF Secretariat)

--001a114419b0804ae7055d07a51e-- From nobody Fri Nov 3 02:35:49 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E43C13FD34 for ; Fri, 3 Nov 2017 02:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz4Vt2VByUDk for ; Fri, 3 Nov 2017 02:35:35 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F31113FD33 for ; Fri, 3 Nov 2017 02:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1509701733; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=4269; bh=E+6tZZkfT7kYKyvkA9iU9po6cfkV3aOxICCVf0PjKPs=; b=fLtFPQATEXU210BegNXfamw3SgNkxesY9UHsBcORshCogHquVBxcVj535HByVs5I V494uxZAjX+Xx+houEYzFNpdzaudhe7WR8bOAzkBGzz0XMEez+61Nbc8F4QBp5hJ2LV MUMGgFpAnXn5mFUxUQ5YQpnodomeLivHsGFUksn4= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1509701733094975.2823812101356; Fri, 3 Nov 2017 02:35:33 -0700 (PDT) Date: Fri, 03 Nov 2017 09:35:33 +0000 From: Denis Ovsienko To: Message-ID: <15f813c4ae0.bf34facf71994.5709848424063476610@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Nov 2017 09:35:47 -0000 ---- On Tue, 31 Oct 2017 19:02:15 +0000 Juliusz Chroboczek wrote ---- >> The way Babel is currently specified allows a protocol instance think it >> has a 2-way exchange with a neighbour, whereas in reality it can be just >> fed with replayed old packets. > >Correct. Without any extra security protocol, Babel is vulnerable to >spoofed or replayed packets. It is expected that it is layered over >a security protocol that protects against spoofed and replayed packets >(be it DTLS, IPsec, WPA2 or 7298bis). > >I've tried to make that clear in the Security Considerations section. Hello all. I confirm the text says that and I understand what it means and it was an OK statement for RFC 6126 but for 6126-bis we had the security requirement upfront. The base specification has a bit to do with that requirement because the "security is not my problem" mindset tends to result in issues like DDoS amplification -- difficult or impossible to fix afterwards if was not considered early. In this case, for instance, if a random network device starts to repeat continuously the packets it has seen before, such failure should not mangle the routing topology, that would be a clear failure to fail. The correct behaviour would be to fail the affected neighbour(s) out and let the topology do its work. >> That's the way the protocol is literally specified, no matter what was >> originally meant and what comments were made on the mailing list or in >> person. > >That is the way the protocol is specified, and that is the intent. Even in that case the document must explain it better. I had read RFC 6126 several times and still missed this point until years later, none of RFC 7298 reviewers noticed it either. Letting future readers of RFC 6126-bis have the same problem would be wrong. >> The way it is commonly specified for other protocols involves a nonce or >> another proof of freshness. > >This is simply not true, Denis. To take an example that you quote >(incorrectly) in your previous mail, OSPF does not use a stateful >handshake (see Section A.3.2 of RFC 2328). Yet, Section 7.1 of RFC 2328 >says this: > > The Hello Protocol is responsible for establishing and > maintaining neighbor relationships. It also ensures that > communication between neighbors is bidirectional. > > [...] > > After a neighbor has been discovered, bidirectional > communication ensured... > >In other words, RFC 2328 uses "bidirectional communication" to mean >exactly the same property that Babel calls "bidirectional reachability". Let me point out that in this OSPF example I refer to the "DD sequence number", which is a field in the Database Description packet, and you respond discussing Hello packets. This very argument exchange itself follows the protocol exchange we are supposedly discussing: one speaker sends a message with a nonce, another speaker returns a packet with a different nonce, so the first speaker concludes there is no two-way communication with the second one. Does the irony of this situation help to make anything across? Back to OSPF, you are right -- it didn't get Hello right, but it tried to get DBDesc right, and made enough steps in the right direction to be one of the good examples. >Denis, I'll remind you what you said at IETF-97: > > The base protocol specification defines no means > to relate a received IHU TLV to any of the recently > sent Hello TLVs. The authentication mechanism > design did not account for this property at the time > and hence did not include its own measures to > address it. > > On the bright side is that now the time would be > good to solve this in either the base protocol or > the authentication mechanism or both. > >I'd like to understand why your position has changed so radically since >then, and why you now believe that this must absolutely be solved in the >base protocol. Excuse me, but to the best of my understanding my position did not change and what I have stated stands as before, even though we are 3 months behind the schedule. As a working group member I never intended to rush publications "no matter what". If a document makes it through, it must be accurate and it should be useful. -- Denis Ovsienko From nobody Fri Nov 3 09:35:25 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9BE13FED7 for ; Fri, 3 Nov 2017 09:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=apple.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 qwqoN61_EpWm for ; Fri, 3 Nov 2017 09:35:22 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 0C51613FEE9 for ; Fri, 3 Nov 2017 09:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1509726921; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hX5wMCklgOZE7irT7iKk0NaqFR2zTug6YKzxJFdg0GI=; b=mz8OpEoa0MvPMMbm1SsIOj1znNy0O2AtlWYPJu84NN81dPRcyCgyt7+t96yE7vIc cAwMe1NLCF4C0DsjLJDc8W71NUR3J2y17aha6dFc2J8cW7CHsRwVNytebOWSqQN4 xRdA3jQcQ/HM5VuPVbcoUl2UdwSuCG54XLg9X7998Ff/ZdDw/9kMKsJBsELQfRE6 eF4En7VFLAlLPbtkV0716nJ9+EVCFgTeJoXhQGyQvEUWeSxfGUkgRGCJkQuTvWPM GRcVugt1Vkhm3eH/K4yVZTKpCAJ7Mr/sCYxk8IR4dSSlpBtTLKAAvqktuCbZQPcE LNenYwXZN43ie6LgRQREMw==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 6D.2E.08732.9CA9CF95; Fri, 3 Nov 2017 09:35:21 -0700 (PDT) X-AuditID: 11973e16-7b5ff7000000221c-af-59fc9ac9ad33 Received: from kencur.apple.com (kencur.apple.com [17.151.62.38]) by relay4.apple.com (Apple SCV relay) with SMTP id 63.74.31187.9CA9CF95; Fri, 3 Nov 2017 09:35:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.114.154.153] (unknown [17.114.154.153]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OYU00BRKOQXXZ10@kencur.apple.com>; Fri, 03 Nov 2017 09:35:21 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi X-Priority: Medium In-reply-to: <15f813c4ae0.bf34facf71994.5709848424063476610@ovsienko.info> Date: Fri, 03 Nov 2017 09:35:20 -0700 Cc: babel@ietf.org Message-id: References: <15f813c4ae0.bf34facf71994.5709848424063476610@ovsienko.info> To: Denis Ovsienko X-Mailer: Apple Mail (2.3445.1.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FAYrnty1p9Ig3t3TSy2LOpmsZhz6zuL A5PHkiU/mTxWnNzIFsAUxWWTkpqTWZZapG+XwJXx7dtTpoJ9ahXbvy9ibWA8JtfFyMEhIWAi seirRBcjF4eQwGomia5rf5lh4pv2FELENzFKfG5uBIpzcvAKCEr8mHyPBaSGWUBe4uB5WZAw s4CWxPdHrSwQ9a1MEgsPXWAHSQgLSEt0XbjLCmFHSsye0MYG0ssG1HBgjRFIWEJASGLLjrmM IDangJfE5rZVYOUsAqoSr5feYYGYLyRx5toMFogTbCTmfngMNl5IwFPid8NHsHoRAQ2JL1vm MUPMVJQ4MnMOM8g9EgIT2CTmbjnMPoFRZBaSF2YhvDALyQsLGJlXMQrlJmbm6GbmmeslFhTk pOol5+duYgQF+3Q7sR2MD1dZHWIU4GBU4uHlmPw7Uog1say4MvcQozQHi5I4r95WoJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGDTd15BOfzJtw+uAKr5papUo98/z5hj2CwZ2/ZvmtFT4X tk2r+dhbw4/TV8rmzXpzvfch12fLjJB4vmPPT71M2G4x+cS1tCiT9X8NhYPqG8UOrXrHJLJj iZKE1HvrDr3/C/c+eSp584DNrZz7N5Z5tpr1tV32cTDRZnX8l/jPtqqFrfbH6txzSizFGYmG WsxFxYkAH1xD5FcCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUiON1OTffkrD+RBk8/G1psWdTNYjHn1ncW ByaPJUt+MnmsOLmRLYApissmJTUnsyy1SN8ugSvj27enTAX71Cq2f1/E2sB4TK6LkYNDQsBE YtOewi5GLg4hgU2MEp+bG5m7GDk5eAUEJX5MvscCUsMsIC9x8LwsSJhZQEvi+6NWFoj6ViaJ hYcusIMkhAWkJbou3GWFsCMlZk9oYwPpZQNqOLDGCCQsISAksWXHXEYQm1PAS2Jz2yqwchYB VYnXS++wQMwXkjhzbQYLxAk2EnM/PAYbLyTgKfG74SNYvYiAhsSXLfOYIWYqShyZOYd5AqPg LCRXz0K4ehaSqxcwMq9iFChKzUmsNNFLLCjISdVLzs/dxAgKz4bC8B2M/5ZZHWIU4GBU4uHd MOF3pBBrYllxZe4hRgkOZiUR3pdFfyKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8xbM/xEpJJCe WJKanZpakFoEk2Xi4JRqYHQpU/2W4RjEJ7Ga5WnXId3SGxk88yvOSLzQC0ywW60ovFwsT0/+ tO0ODYf8gn3L1tbYdi9fHt41b8/CFzPtyyZ62ORo/Tq7e1eoOtfeN/ERM/Y+d338WWJZ/E61 1jMJwpsuWWxat9u9x9Zv/g+Jgr3H9nkYGBUmNBreC7zfUea1uC8lROC3nxJLcUaioRZzUXEi ANVbdEZLAgAA Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Nov 2017 16:35:25 -0000 Hi Denis, If we added a paragraph to the security considerations section that clearly explains this issue and explicitly states that any extension that secures Babel should take this into account, would that work for you? Thanks, David > On Nov 3, 2017, at 02:35, Denis Ovsienko wrote: > > ---- On Tue, 31 Oct 2017 19:02:15 +0000 Juliusz Chroboczek wrote ---- >>> The way Babel is currently specified allows a protocol instance think it >>> has a 2-way exchange with a neighbour, whereas in reality it can be just >>> fed with replayed old packets. >> >> Correct. Without any extra security protocol, Babel is vulnerable to >> spoofed or replayed packets. It is expected that it is layered over >> a security protocol that protects against spoofed and replayed packets >> (be it DTLS, IPsec, WPA2 or 7298bis). >> >> I've tried to make that clear in the Security Considerations section. > > Hello all. > > I confirm the text says that and I understand what it means and it was an OK statement for RFC 6126 but for 6126-bis we had the security requirement upfront. > > The base specification has a bit to do with that requirement because the "security is not my problem" mindset tends to result in issues like DDoS amplification -- difficult or impossible to fix afterwards if was not considered early. > > In this case, for instance, if a random network device starts to repeat continuously the packets it has seen before, such failure should not mangle the routing topology, that would be a clear failure to fail. The correct behaviour would be to fail the affected neighbour(s) out and let the topology do its work. > >>> That's the way the protocol is literally specified, no matter what was >>> originally meant and what comments were made on the mailing list or in >>> person. >> >> That is the way the protocol is specified, and that is the intent. > > Even in that case the document must explain it better. I had read RFC 6126 several times and still missed this point until years later, none of RFC 7298 reviewers noticed it either. Letting future readers of RFC 6126-bis have the same problem would be wrong. > >>> The way it is commonly specified for other protocols involves a nonce or >>> another proof of freshness. >> >> This is simply not true, Denis. To take an example that you quote >> (incorrectly) in your previous mail, OSPF does not use a stateful >> handshake (see Section A.3.2 of RFC 2328). Yet, Section 7.1 of RFC 2328 >> says this: >> >> The Hello Protocol is responsible for establishing and >> maintaining neighbor relationships. It also ensures that >> communication between neighbors is bidirectional. >> >> [...] >> >> After a neighbor has been discovered, bidirectional >> communication ensured... >> >> In other words, RFC 2328 uses "bidirectional communication" to mean >> exactly the same property that Babel calls "bidirectional reachability". > > Let me point out that in this OSPF example I refer to the "DD sequence number", which is a field in the Database Description packet, and you respond discussing Hello packets. This very argument exchange itself follows the protocol exchange we are supposedly discussing: one speaker sends a message with a nonce, another speaker returns a packet with a different nonce, so the first speaker concludes there is no two-way communication with the second one. Does the irony of this situation help to make anything across? > > Back to OSPF, you are right -- it didn't get Hello right, but it tried to get DBDesc right, and made enough steps in the right direction to be one of the good examples. > >> Denis, I'll remind you what you said at IETF-97: >> >> The base protocol specification defines no means >> to relate a received IHU TLV to any of the recently >> sent Hello TLVs. The authentication mechanism >> design did not account for this property at the time >> and hence did not include its own measures to >> address it. >> >> On the bright side is that now the time would be >> good to solve this in either the base protocol or >> the authentication mechanism or both. >> >> I'd like to understand why your position has changed so radically since >> then, and why you now believe that this must absolutely be solved in the >> base protocol. > > Excuse me, but to the best of my understanding my position did not change and what I have stated stands as before, even though we are 3 months behind the schedule. > > As a working group member I never intended to rush publications "no matter what". If a document makes it through, it must be accurate and it should be useful. > > -- > Denis Ovsienko > > > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Sat Nov 4 10:59:30 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4328C13FBC7 for ; Sat, 4 Nov 2017 10:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 vaz69QKJVi-8 for ; Sat, 4 Nov 2017 10:59:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7EE13FBC8 for ; Sat, 4 Nov 2017 10:59:24 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA4HxLZ4021872 for ; Sat, 4 Nov 2017 18:59:22 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 05793EB21F for ; Sat, 4 Nov 2017 18:59:22 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9H3nKKMP_oLi for ; Sat, 4 Nov 2017 18:59:21 +0100 (CET) Received: from trurl.irif.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C3301EB217 for ; Sat, 4 Nov 2017 18:59:20 +0100 (CET) Date: Sat, 04 Nov 2017 18:59:21 +0100 Message-ID: <87a802orgm.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 04 Nov 2017 18:59:22 +0100 (CET) X-Miltered: at korolev with ID 59FDFFF9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59FDFFF9.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 : 59FDFFF9.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] Babel protocol X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Nov 2017 17:59:29 -0000 http://media.comicbook.com/2017/10/the-flash-babel-protocol-1038471.jpg From nobody Sat Nov 4 14:19:59 2017 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 6395913FB6C; Sat, 4 Nov 2017 14:19:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.64.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150983039829.26601.3109842491855567125@ietfa.amsl.com> Date: Sat, 04 Nov 2017 14:19:58 -0700 Archived-At: Subject: [babel] Rtgdir early review of draft-ietf-babel-source-specific-01 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 List-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, 04 Nov 2017 21:19:58 -0000 Reviewer: Joel Halpern Review result: Not Ready This is a routing directorate early review. It is intended to assist the working group and the routing ADs in processing the advancing document. This document is nearly ready for publication as a Proposed Standard RFC. Isses: Major: N/A Moderate: Please address the issues reported by id-nits. Specifically, repair the abstract and add an explicit reference to RFC 2119 Please add an informative reference to draft-ietf-rtgwg-dst-src-routing indicating the the routing policy described here aligns with the ongoing work in the routing area for how to handle source specific routes. This could be added in section 4. The base Babel (bis) specification does not talk about the handling of duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed on a given destination prefix advertisement? Please indicate what the intended / permitted handling is in the text. Minor: As far as I can tell, the behavior described in section 3.1 for 0/0 source addresses and their relationship to routes without source addresses is correct and matches draft-ietf-rtgwg-dst-src-routing. However, the wording is sufficiently different as to cause this reader to wonder about it. If practical consider additional wording to make the alignment clear. This would seem to apply to 3.2 as well. The most obvious fix is to say that a Babel node supporting this extensions treats all advertisements received without a source specific prefix as if they had the 0/0 source prefix? (The text in section 5.2 says this. I would like to see it in section 3.1) From nobody Sat Nov 4 15:25:06 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7210413FBC0 for ; Sat, 4 Nov 2017 15:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtyBpQCKwF6i for ; Sat, 4 Nov 2017 15:25:03 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873A313FADA for ; Sat, 4 Nov 2017 15:25:03 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1509834295; bh=DRo7pfMZYruE4Bx9IukhXqZkrMSGznMa9bhcB5o4nm8=; h=From:To:Subject:In-Reply-To:References:Date:From; b=W+O4NkM7rtmTJmQKqCR8KaKGEYnFDFnBMpD8UH8KVB2o8ukQjWMdxyXvtQjtQNl9D reORsueNiE7nLFDDEXL+IGI/95NWwVQ2rTT4Z8gQIVTjRIm2eQpd9pGIVYLM68Kq9n hxQz4tDcqnDv8vaa0azw/okPivCPJhX7cMql9uExYPb5+O5Hy49IpIFAnrIKGIfVa/ 6OfxGwNJwMUuJQ9ko5HAxYOlJSDwSaNvkO6d7qGUqqDSuWDBE4bVc8RCpyE1si3T5V GAU27eX3xTeg3cW64awS5g2Pkroig9Dn+dd7frC3vZ0x+FQk5Ys1n6kLwtn/sKMLZ9 xjLwOJzwihqGQ== To: Juliusz Chroboczek , babel@ietf.org In-Reply-To: <87a802orgm.wl-jch@irif.fr> References: <87a802orgm.wl-jch@irif.fr> Date: Sat, 04 Nov 2017 23:24:24 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871sldn0mf.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Babel protocol X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Nov 2017 22:25:05 -0000 Juliusz Chroboczek writes: > http://media.comicbook.com/2017/10/the-flash-babel-protocol-1038471.jpg Ha! So that's how The Flash navigates at light speed ;) But yeah, I also usually keep by router next to my pulse cannon and fire suppression device :D -Toke From nobody Mon Nov 6 07:48:02 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5BF13FAD9 for ; Mon, 6 Nov 2017 07:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7zm6eaJLP_n for ; Mon, 6 Nov 2017 07:48:00 -0800 (PST) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797EB13FC44 for ; Mon, 6 Nov 2017 07:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1509983276; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1486; bh=TLLg0tke2wPtqOHSrW27LOk0Ahx450SjxpaWfuuObwg=; b=uhxi/Kp/xgjbP2ho7slQJ0d43rosQuXuvsj8FH9zkEjJ3ImF1RudWu/i1sHgF5qg pFsCSwAABzOQoo5W0WUq2skPhw/6ZFlZS953SZ9XqoB4jEkJiHvomWKtmHRp+EZCyNz JnCggc2PT6CGp2RTDaL/S6I3h3NaqGd4dkEDt0L0= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1509983276794891.9083340970092; Mon, 6 Nov 2017 07:47:56 -0800 (PST) Date: Mon, 06 Nov 2017 15:47:56 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> In-Reply-To: <87r2tikl1e.fsf@toke.dk> References: <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Nov 2017 15:48:02 -0000 ---- On Wed, 01 Nov 2017 16:42:37 +0000 Toke H=C3=B8iland-J=C3=B8rgensen w= rote ----=20 >Hi Denis=20 >=20 >I think this is the critical point:=20 >=20 >> The text says "ascertains bidirectional reachability" and in the=20 >> network protocols language this is a statement with a meaning.=20 >=20 >Which "network protocols language" are you referring to?=20 >=20 >As I said, I did not get the same specific meaning out of Section 3.4=20 >when I first read it; and I have not been able to find a definition of=20 >this term anywhere through my (admittedly limited) googling. So if you=20 >could provide a reference, that would be helpful :)=20 Hello Toke. The "network protocols language" I was referring to does not have a definit= e normative reference as far as I know. It is a vague set of related concep= ts, but it gets more clear with studying specifications and implementations= . If the goal was only to state exactly what to do, source code would work. H= owever, the goal of the specification is to make it clear to the readers wh= at was originally meant and what they can reasonably expect from an impleme= ntation. On one hand, a reader may interpret an under-specified text the way they me= an, not the way the author means. On the other, over-specified text ultimat= ely becomes a source code. Finding the right balance is a vague problem, as= far as I see using the right language helps to make it smaller. --=20 Denis Ovsienko From nobody Mon Nov 6 07:50:50 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25A113FB00 for ; Mon, 6 Nov 2017 07:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uW8QgtALCKt for ; Mon, 6 Nov 2017 07:50:46 -0800 (PST) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23E513FAD9 for ; Mon, 6 Nov 2017 07:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1509983443; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=446; bh=Ta+GGwiOW6jifusiffjVkZWqMg5hU7bBzflD9EPnX7M=; b=gHPjoFc9pC/FaeG/eySpa1C+4Bvne9xH6doyDiNnSfNgQGVRv61sHMcb9O90PmGF 7xCboNFkcf3u+OyUI5El2AtR47cVvyrix2CH6tV9sXJ09IWs4sarlMnqaDhjYK/lDmC qLmi4dxLXbdzRqJd9YTSHcRb9yTU1zxjM4Db/LWM= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1509983443292243.79495930801227; Mon, 6 Nov 2017 07:50:43 -0800 (PST) Date: Mon, 06 Nov 2017 15:50:43 +0000 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <15f9206d95a.c73f512d5483.2275129108310066189@ovsienko.info> In-Reply-To: References: <15f813c4ae0.bf34facf71994.5709848424063476610@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Nov 2017 15:50:48 -0000 ---- On Fri, 03 Nov 2017 16:35:20 +0000 David Schinazi wrote ---- > Hi Denis, > > If we added a paragraph to the security considerations section that clearly explains > this issue and explicitly states that any extension that secures Babel should take > this into account, would that work for you? Hello David. Well, yes, stating the problem is a good first step in getting it solved. -- Denis Ovsienko From nobody Tue Nov 7 17:42:03 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BE612EAA6 for ; Tue, 7 Nov 2017 17:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYjrbDR_AYFe for ; Tue, 7 Nov 2017 17:42:00 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498FF12EA24 for ; Tue, 7 Nov 2017 17:42:00 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1510105312; bh=GWxFlAdtjp/pv+sKL/1I00f49fPfW+BUsoqffmfKnIE=; h=From:To:Subject:In-Reply-To:References:Date:From; b=Mt4/+LrWhOJo1l0NUrFgshLuBJPwtQPwv1PIhD/jN6F/0wblbjHCteJcLzc1quD1s H7DytN872XB6e7G47XGnpK+q4FB6JUSR4K8Db1bum5AghSpz/it70nA8/nYpBKQ+j2 8Klca8Mcr3wcZLiOr1PnZ86u0hRx3GfEs+Fdrli2w5OCXrOpvbyZ/ZG1RtfzevlOkE RQlywXrTYtEi/AoudDmXYKz9zBx+Hu+VQri204POqtWP3/sSx7jwvXdgkrT+9VD3pS ZhMxZY+awRi64ya/ZUTlS4vr893zzqTf9dOH+3cYvfAzJRYXoZtQYzBdj7vPhvhsrg 8oXctzjP/on1Q== To: Denis Ovsienko , Babel at IETF In-Reply-To: <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> References: <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> Date: Wed, 08 Nov 2017 10:41:45 +0900 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y3nhr1gm.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Nov 2017 01:42:02 -0000 Denis Ovsienko writes: >>Which "network protocols language" are you referring to? >> >>As I said, I did not get the same specific meaning out of Section 3.4 >>when I first read it; and I have not been able to find a definition of >>this term anywhere through my (admittedly limited) googling. So if you >>could provide a reference, that would be helpful :) > > The "network protocols language" I was referring to does not have a > definite normative reference as far as I know. It is a vague set of > related concepts, but it gets more clear with studying specifications > and implementations. Right, but that makes it one of those things that reasonable people can disagree on. Which I guess what is going on here. Now, seeing as the problem this creates is a security issue, I agree with David that the security considerations section is the place to add a note. So an way to fix this would be adding something like this to the first paragraph of section 6 (some wordsmithing probably needed): "In particular, the bidirectional reachability detection in Babel is not a full handshake and does not offer any security guarantees (such as replay protection). Any security extensions to Babel need to take this into account." Would this address your concerns, do you think? :) -Toke From nobody Wed Nov 8 07:04:49 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058D41275C5; Wed, 8 Nov 2017 07:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8AldrNx0MXt; Wed, 8 Nov 2017 07:04:46 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AAC126557; Wed, 8 Nov 2017 07:04:45 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA8F4hbG006905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Nov 2017 16:04:43 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vA8F4hPD022175; Wed, 8 Nov 2017 16:04:43 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 49FCEEB259; Wed, 8 Nov 2017 16:04:43 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id w5A8geeJmKDr; Wed, 8 Nov 2017 16:04:37 +0100 (CET) Received: from mac-matthieu.lan (AAubervilliers-652-1-188-235.w86-218.abo.wanadoo.fr [86.218.75.235]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id EDAD0EB216; Wed, 8 Nov 2017 16:04:36 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Matthieu Boutier In-Reply-To: <150983039829.26601.3109842491855567125@ietfa.amsl.com> Date: Wed, 8 Nov 2017 16:04:35 +0100 Cc: rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3445.4.7) 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, 08 Nov 2017 16:04:43 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 08 Nov 2017 16:04:43 +0100 (CET) X-Miltered: at korolev with ID 5A031D0B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5A031D0B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5A031D0B.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5A031D0B.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 : 5A031D0B.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5A031D0B.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] Rtgdir early review of draft-ietf-babel-source-specific-01 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Nov 2017 15:04:48 -0000 Hi, Thank's a lot for this early review. > Please address the issues reported by id-nits. Please accept my apologizes about these nits. > The base Babel (bis) specification does not talk about the handling of > duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed on = a given > destination prefix advertisement? I believe it is clear that a Babel node MUST NOT send two Source Prefix = sub-TLVs in one TLV. But If a received TLV has two Source Prefix sub-TLVs, I = hesitate: does a node SHOULD or MUST ignore the whole TLV? Does the list have an opinion? Matthieu From nobody Wed Nov 8 07:41:12 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C639127775 for ; Wed, 8 Nov 2017 07:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQbXLVtDieRY for ; Wed, 8 Nov 2017 07:41:10 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0365127843 for ; Wed, 8 Nov 2017 07:41:09 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA8Ff8QS031212; Wed, 8 Nov 2017 16:41:08 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 26C32EB21F; Wed, 8 Nov 2017 16:41:08 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9S9VEtJ-JSrb; Wed, 8 Nov 2017 16:41:07 +0100 (CET) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3D5A5EB217; Wed, 8 Nov 2017 16:41:07 +0100 (CET) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1eCSTS-0008Vj-V0; Wed, 08 Nov 2017 16:41:07 +0100 Date: Wed, 08 Nov 2017 16:41:06 +0100 Message-ID: <7ifu9ozskt.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Denis Ovsienko , Babel at IETF In-Reply-To: <87y3nhr1gm.fsf@toke.dk> References: <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 08 Nov 2017 16:41:08 +0100 (CET) X-Miltered: at korolev with ID 5A032594.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5A032594.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 : 5A032594.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Nov 2017 15:41:11 -0000 > Now, seeing as the problem this creates is a security issue, I agree > with David that the security considerations section is the place to add > a note. So an way to fix this would be adding something like this to the > first paragraph of section 6 (some wordsmithing probably needed): I don't agree. Babel is a completely insecure protocol. It MUST therefore be used together with a hop-to-hop security mechanism. Depending on the deployment model, this could be one of the following: * physical layer security (e.g. physically secured Ethernet); * link-layer security (e.g. WPA2, 802.1X, VPN); * network-layer security (e.g. IPsec); * transport-layer security (e.g. DTLS); * application-layer security (e.g. 7298bis). If Babel is not properly secured, it is vulnerable to a wide range of attacks (lower-metric, higher seqno, longer prefix, Hello-based DoS, IHU-based DoS, etc.) This is something that must be made perfectly clear to the reader. > "In particular, the bidirectional reachability detection in Babel is not > a full handshake and does not offer any security guarantees (such as > replay protection). Any security extensions to Babel need to take this > into account." Singling out this particular property is misleading for many reasons. It implies that this is the most serious vulnerability in unsecured Babel, which is simply not true. It also implies that a reliable three- or four-way handshake does offer some sort of security guarantees, which it does not. In effect, the user will find himself wondering whether he missed something. In short, your suggestion makes the document less rather than more clear. I would therefore be opposed to adding such a sentence. -- Juliusz From nobody Wed Nov 8 10:32:30 2017 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D53129AC9 for ; Wed, 8 Nov 2017 10:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snBtsYQqysRB for ; Wed, 8 Nov 2017 10:32:15 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 F20CA129AA4 for ; Wed, 8 Nov 2017 10:32:14 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id g6so2542368pgn.6 for ; Wed, 08 Nov 2017 10:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GTH34hy66pl1WDaXWHUBy7w+OtJA/gVBKFuC1A0c0FY=; b=Qoork+vGQtRsjOCTZjgTpo6i8LjvHLfeYO2oGf6Z6YfaYm5JWU//h/FOsmZC8RXAYS 542pETFtyn3HIyc8cjL0T2pzfsOA09izLQsUv6qPUceFYEu5yrlkDh/8vIbT1N0ZICCv S057LX9ElWEj0u1+Cp88czP4y10HexqpyUf8mEyyoxMutTkE3BQNFElqGZrNumSdUAE7 CEoZHCehb5yGQgO/6AaYSPGPNRkHLPPxEtn4vUAZ0uRltlHKo6/7ukKgHc5yZGw8ZoHL 69PnjVFr4OrgX1pe4Yy5XlZEmjYJ5diLE+L4mvg9H4h2rB3P6T1O+aBKJWPenPyBo5sZ zIQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GTH34hy66pl1WDaXWHUBy7w+OtJA/gVBKFuC1A0c0FY=; b=jSS0JtmmA2pyso2nkaQyIkIcMg+r2aOyRQNDiR3lsCx4a1tsJ3b3uB3RZM9Wa1Wzws 6XIk9xjxPSpONA3uvqV79fYMWD3kFQdphDd29Cl56Tl8UJMzog4yVfn/9axk2mN0U0nW bcvUMTci0XRr/UZWJgYNHyZjLq4RfrMzjyBvGHmex7ldTKseRZalAM8+q7z1ikhkIOCb QGCJux7d+/xY8cd29v7xtYGFC9Y3CPI/xDsn5K+pcAbzLQ2fFi4XImDL0bYQFuNoN//I 44pxwenaS+zIwHiNJbHOb5lZHlB/NStBhWL1CwVn3gLRpQkCklyvxWdFMT6RI9oMSKDN 9W9w== X-Gm-Message-State: AJaThX4JCeemEXZBhlPVXLL2qZNzp7U+N4tfuMlzohU2H1pRiv9IybEP fheKO4EpNedby2kdIMUnTEQlmg== X-Google-Smtp-Source: ABhQp+RbM+Us2WTerYsK2e7o65wR7rJH0Ef3PFwkL2eSQrlh6LXh3K9fs7IH0MVdsqQb4H6FgyiGtw== X-Received: by 10.98.246.22 with SMTP id x22mr1386429pfh.87.1510165934313; Wed, 08 Nov 2017 10:32:14 -0800 (PST) Received: from ?IPv6:2620::10e7:10:a7:873a:8815:2067? ([2620:0:10e7:10:a7:873a:8815:2067]) by smtp.gmail.com with ESMTPSA id d12sm10198715pfl.140.2017.11.08.10.32.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 10:32:13 -0800 (PST) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E1282314-8BD4-40E8-BC0A-7020C19433D8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 10:32:17 -0800 In-Reply-To: <7ifu9ozskt.wl-jch@irif.fr> Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Denis Ovsienko , Babel at IETF To: Juliusz Chroboczek References: <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Nov 2017 18:32:17 -0000 --Apple-Mail=_E1282314-8BD4-40E8-BC0A-7020C19433D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 8, 2017, at 07:41, Juliusz Chroboczek wrote: >=20 >> "In particular, the bidirectional reachability detection in Babel is = not >> a full handshake and does not offer any security guarantees (such as >> replay protection). Any security extensions to Babel need to take = this >> into account." >=20 > Singling out this particular property is misleading for many reasons. = It > implies that this is the most serious vulnerability in unsecured = Babel, > which is simply not true. The current text of the Security Considerations section already offers = an example of a vulnerability in unsecured Babel. >>> Any attacker can misdirect data traffic by advertising routes = with a >>> low metric or a high seqno Which strikes me as rather more serious than replay attacks on the = bidirectional reachability detection. > In short, your suggestion makes the document less rather than more = clear. > I would therefore be opposed to adding such a sentence. Perhaps some compromise can be found by strengthening the admonition in = the Security Considerations section to use a hop-to-hop security = mechanism according to the deployment model, and to provide a more = detail list of the vulnerabilities available when that security layer is = breached. --james woodyatt > --Apple-Mail=_E1282314-8BD4-40E8-BC0A-7020C19433D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Nov 8, 2017, at 07:41, Juliusz Chroboczek <jch@irif.fr> wrote:

"In = particular, the bidirectional reachability detection in Babel is not
a full handshake and does not offer any security guarantees = (such as
replay protection). Any security extensions to = Babel need to take this
into account."

Singling out this particular = property is misleading for many reasons.  It
implies = that this is the most serious vulnerability in unsecured Babel,
which is simply not true.

The current text of the Security Considerations = section already offers an example of a vulnerability in unsecured = Babel.

   Any attacker =
can misdirect data traffic by advertising routes with a
   low metric or a high =
seqno

Which strikes me as rather more serious than =
replay attacks on the bidirectional reachability detection.

In short, your suggestion makes the document less rather than =
more clear.
I would therefore be opposed to adding such a =
sentence.

Perhaps some compromise can be found by =
strengthening the admonition in the Security Considerations section to =
use a hop-to-hop security mechanism according to the deployment model, =
and to provide a more detail list of the vulnerabilities available when =
that security layer is breached.



--james woodyatt <jhw@google.com>







=

--Apple-Mail=_E1282314-8BD4-40E8-BC0A-7020C19433D8--


From nobody Wed Nov  8 10:41:10 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3BA129537 for ; Wed,  8 Nov 2017 10:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zPTdHmiVk97 for ; Wed,  8 Nov 2017 10:41:06 -0800 (PST)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4D3129AC5 for ; Wed,  8 Nov 2017 10:40:59 -0800 (PST)
Received: by mail-wr0-x229.google.com with SMTP id j15so3313621wre.8 for ; Wed, 08 Nov 2017 10:40:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9bW1KKg6QIxaGTWTmnx77XK6r0R0EGaZuBLVVbKEp04=; b=YbqnkJSPIoyHkmGyNfQquk0Ra44JmMJAZwHARTXbcviSgxHCgNPUW/ocz0y7yGJHSO 1aXTNMzmuBVdC+jByvOW9uKrfDz9scmrBbGmxxm+5LZrOioPbgm/tGWXVM4zr1zG6e2U T8yDbPZLbj7S/Bvm7mdFfAlG/f0rdQ6APxwB28+Cj4v3Ieb8SLecmxs/3m38/28qFuDD JueiiKHEpeEWX4GcyEaX4sZBecOvNg9bWH/38mWBHO6v5cbpYmNP/VCHsJUh3/LfIL47 JYljWq8ZfqC6MYp9I3cWsfDHmlToLYmSDV6eAmf2J3x6yq0owK5yo8+Y3ZINh1jW/i3g T9Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9bW1KKg6QIxaGTWTmnx77XK6r0R0EGaZuBLVVbKEp04=; b=Iqux/jkh+cBdArI/5P0c84klZp4q9sFHHb3OKdHhj1pCXBLng2oPeT+jAIjdsmkfrq J+/UwPwqEH31Up3D24bWkny8NuX01yiFFWkWsb8lATW7L1UOPI56w0pqcgUEbww0WpXV sdx2rfukWKPxpmh5BfHNvpHVLKTlb46+yTWCHGKymEcfqf5gqX/yZLXM46+ka3tyY0xf qHe620s5TnVdRiM/mUbEMPucoTCDVfYSrc/ZbGgpvPckd/tRPtvRp02RqSo7Qqg9PxQ8 nUYpzAlcan09gEN0CJibiOmxR5+NjnAOPgfnVFFm9BkyvO22CQDqXKSM9G9QcTzZmvHl 38fA==
X-Gm-Message-State: AJaThX442DiO15Zq5emueTXC0Oe9kCXYSShEzqhYQRUvh6UVsZrnevhJ XUMdS8MI5a3/iqno/TqXzpx/XQER3BhTUXbA4OI=
X-Google-Smtp-Source: ABhQp+Ru8Gou32PHGS3+XEJ/bd5BmGeF+S6epEnSjlZTzWNMemDWRjetXma7tQXUcGlef+XswedK1ZRyWyKJ0lDlEgg=
X-Received: by 10.223.196.247 with SMTP id o52mr1245763wrf.119.1510166458227;  Wed, 08 Nov 2017 10:40:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.150.10 with HTTP; Wed, 8 Nov 2017 10:40:57 -0800 (PST)
In-Reply-To: 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr> 
From: Alia Atlas 
Date: Wed, 8 Nov 2017 13:40:57 -0500
Message-ID: 
To: james woodyatt 
Cc: Juliusz Chroboczek , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= ,  Denis Ovsienko , Babel at IETF 
Content-Type: multipart/alternative; boundary="f403045f55264b61ba055d7d075e"
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 08 Nov 2017 18:41:09 -0000

--f403045f55264b61ba055d7d075e
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 8, 2017 at 1:32 PM, james woodyatt  wrote:

> On Nov 8, 2017, at 07:41, Juliusz Chroboczek  wrote:
>
>
> "In particular, the bidirectional reachability detection in Babel is not
> a full handshake and does not offer any security guarantees (such as
> replay protection). Any security extensions to Babel need to take this
> into account."
>
>
> Singling out this particular property is misleading for many reasons.  It
> implies that this is the most serious vulnerability in unsecured Babel,
> which is simply not true.
>
>
> The current text of the Security Considerations section already offers an
> example of a vulnerability in unsecured Babel.
>
>    Any attacker can misdirect data traffic by advertising routes with a
>    low metric or a high seqno
>
>
> Which strikes me as rather more serious than replay attacks on the
> bidirectional reachability detection.
>
> In short, your suggestion makes the document less rather than more clear.
> I would therefore be opposed to adding such a sentence.
>
>
> Perhaps some compromise can be found by strengthening the admonition in
> the Security Considerations section to use a hop-to-hop security mechanism
> according to the deployment model, and to provide a more detail list of the
> vulnerabilities available when that security layer is breached.
>

I strongly agree.  At least a mandatory-to-implement hop-to-hop security
mechanism and what attacks it protects against is critical.

Regards,
Alia



> --james woodyatt 
>
>
>
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>
>

--f403045f55264b61ba055d7d075e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On W=
ed, Nov 8, 2017 at 1:32 PM, james woodyatt <jhw@google.com> wro=
te:
<=
span class=3D"">On Nov 8, 2017, at 07:41, Juliusz Chroboczek <jch@irif.fr> wrote:

"In particular, the bidirectional reachability detection=
 in Babel is not
a full handshake and does not offer any security guaran=
tees (such as
replay protection). Any security extensions to Babel need =
to take this
into account."

Singling out this p=
articular property is misleading for many reasons.=C2=A0 It
implies that=
 this is the most serious vulnerability in unsecured Babel,
which is sim=
ply not true.

The curren=
t text of the Security Considerations section already offers an example of =
a vulnerability in unsecured Babel.

 =
  Any attacker can misdirect data traffic by advertising routes with a
   low metric or a high seqno
<=
div>
Which strikes me as rather more serious than repla=
y attacks on the bidirectional reachability detection.

In short, your suggestion makes t=
he document less rather than more clear.
I would therefore be opposed to=
 adding such a sentence.

=
Perhaps some compromise can be found by strengthening the admonition in the=
 Security Considerations section to use a hop-to-hop security mechanism acc=
ording to the deployment model, and to provide a more detail list of the vu=
lnerabilities available when that security layer is breached.

I strongly agree.=C2=A0 At least a mandatory=
-to-implement hop-to-hop security mechanism and what attacks it protects ag=
ainst is critical.

Regards,
Alia=C2=A0

=C2=A0


--james woodyatt <jhw@google.com>








_______________________________________________

babel mailing list

babel@ietf.org

https://www.ietf.org/mailman/listinfo/babel





--f403045f55264b61ba055d7d075e--


From nobody Wed Nov  8 10:42:47 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CE9129ADC for ; Wed,  8 Nov 2017 10:42:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFokLQEPTsG5 for ; Wed,  8 Nov 2017 10:42:43 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C0B12008A for ; Wed,  8 Nov 2017 10:42:43 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id e102so11308lfi.3 for ; Wed, 08 Nov 2017 10:42:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kESioR4TwtcJFBGEMWjWAItWh+skKGIzWqkcfzDCbUk=; b=HEvy2badbRvAU2zTGzVOGAiwqhP+S5xqsFD7o7hc+fs8FP9GrDULUBYR29kQ3hdEkR O2Ip70dg90bKW4HPBy/IidQW8rfqZBq/2U+opNMpK14lVqHoF1zmVTQMCMc2MdXLjBkj s+THIswpYDuB5Yqj056DvM+ehTYxjUfs4850Rji1q1EymDFgFWzgheJxLW1cyM1KA+ov iJjuEd+y3VSnAhHku2QNNVqJBWq9yktZ55Kmg0VMMe7vhgsaaD9kBHUTP9aMpXZxN4Lf mKxf6sCrSmRDnA0JzAWtR+ftQBvvrA/K0sZuKmDRBhvwIbD1hMQoeFo41yS1Cq+yJ9pp 9TCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kESioR4TwtcJFBGEMWjWAItWh+skKGIzWqkcfzDCbUk=; b=gVqQY3WrIeqcv29zvBO35PT5ts0qAs9yTPy8+nHxVqHxm5vwdSUmrbERozrFVRSxBC CUfBlbX5qTxed4Czmolv4uosmiL7475oBV/i81VeuvUGQZJO2e2I+71rUnGNbd1hnbVp 5GuE1vlvvxb43CxZm993rphqiMuqWC2p2njXdqwqZxohwl0bOJpCAVdt0Zdiujq7uVpm 5hfCuWPjg4+9MhQmipNTUVOU9kWi7q93BvKMcYl2k+/f6OUsuY8WxDzNMvPZENGffUwC KpZQYpxWGRwxwQ/bu1g7FdG75XthJzMzZV6PVvfbM5Zdr1WLSHQtF5AhU4w4rUi/N+Z/ hXow==
X-Gm-Message-State: AJaThX4DjWjv7/jrpu3bM8TdeqrzvrVnfiePAlJfJO2FAxiw3d5I+gah lBQFEINzFR3G/eYiAcKp6msF2w==
X-Google-Smtp-Source: ABhQp+SlLtR4yOZKzMcIbmE01LDmDzBVpTi02RLHV7c6K2ImGpy1153dMNNcw+ILtAtPaElWIwBtmQ==
X-Received: by 10.46.25.218 with SMTP id 87mr667607ljz.122.1510166561624; Wed, 08 Nov 2017 10:42:41 -0800 (PST)
Received: from dtdrvwfb2mhn4-s0z5y-4.rev.dnainternet.fi (dtdrvwfb2mhn4-s0z5y-4.rev.dnainternet.fi. [2001:14bb:80:dd19:1036:5197:8fbf:d4c8]) by smtp.gmail.com with ESMTPSA id r29sm930226lje.4.2017.11.08.10.42.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 10:42:40 -0800 (PST)
From: Ted Lemon 
Message-Id: <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4B0747DE-A4D3-451B-8C16-05C98212729F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 8 Nov 2017 20:42:38 +0200
In-Reply-To: 
Cc: james woodyatt , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Denis Ovsienko , Babel at IETF , Juliusz Chroboczek 
To: Alia Atlas 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 08 Nov 2017 18:42:45 -0000

--Apple-Mail=_4B0747DE-A4D3-451B-8C16-05C98212729F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 8, 2017, at 8:40 PM, Alia Atlas  wrote:
> I strongly agree.  At least a mandatory-to-implement hop-to-hop =
security mechanism and what attacks it protects against is critical.

A security model that protects against _anything_ requires it to =
actually be secure.   The current draft has no such mechanism.   So if =
you want to make something MTI, we can't do it with the current draft, =
or we'd be requiring people to implement mickey-mouse security.


--Apple-Mail=_4B0747DE-A4D3-451B-8C16-05C98212729F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 8, 2017, at 8:40 PM, Alia Atlas <akatlas@gmail.com> =
wrote:
I =
strongly agree.  At least a mandatory-to-implement hop-to-hop =
security mechanism and what attacks it protects against is =
critical.

A =
security model that protects against _anything_ requires it to actually =
be secure.   The current draft has no such mechanism.   So if =
you want to make something MTI, we can't do it with the current draft, =
or we'd be requiring people to implement mickey-mouse =
security.

=

--Apple-Mail=_4B0747DE-A4D3-451B-8C16-05C98212729F--


From nobody Wed Nov  8 10:47:38 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536B4129AD5 for ; Wed,  8 Nov 2017 10:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Di9gUhXsTx0y for ; Wed,  8 Nov 2017 10:47:36 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60656129AF9 for ; Wed,  8 Nov 2017 10:47:34 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id b189so12345779wmd.4 for ; Wed, 08 Nov 2017 10:47:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eEH9KVMJmaKGXM8FxLT08gOrTI83Ub6pDd44IXK/OkY=; b=Pzx2v+w9DlglpHOO/Q35E/7HE+BZWULHfeDMY8gnYkDuYoB0hIgvZHKr5tP3WnPoIc wQig6Sqs9EG8XU23eBGyyd0bb6lH4VUvWhKMj1XK3mndN32EvxAAZAIzsE9OUANkumxY r1WPV4yKm/acP+/hu40wK2DjFY95hUVYb72l6PdvmeffMBa4M6ONNSL699LRuLCX6J5+ tJ3s4mkv4vN7Hab5gh+gE6w5JBZh2sfU/EjNbcKjejTtRpyxXL9h/BwoxOQmRTk1CYBU YqJD5KwMvZ57Rk3AJzg03q15WjBUFdgJ39MdtDsmcogcM72x5x+9iLBQm8GzpQESUSVw WAIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eEH9KVMJmaKGXM8FxLT08gOrTI83Ub6pDd44IXK/OkY=; b=EyiqYXYaKa4R8obwZUXvnAObzwCaFa57hdcVchw+4u7JI+5PbJWGo4uN6u7+K5Mr17 qE4BBJ51cvOPj7lrCqglZJ3cpeaLEiNeKzVYGc1+PoPN4d1bBZKZ5cEudLu3GBzAkqg2 taKtcIVXAcoSjDveM2NNNk4iIVnJTarUAXvvCJJxa/y7XVrwyzry6EAoi7Se8RyA9YC0 Hot70EAGOA2wMj3so85NLrF3q3ZQd0HHsTXnj8oPrA0cZYQ3vcqZwzIDGgtL7JXSMYxB ALI54CGaiWC9wehHUkEG5r7G6FIh7+/OK0bKJ2d3TPFmCuSygCWbV0RKVO02GbzJn+e8 dMLQ==
X-Gm-Message-State: AJaThX5Fkpf1Y9gV+Hrf/dJQe5f3PsRg8HwvixZyFg6+TbCC2iH47FYw maFFWvwcZnhNHIjVxsZTrirX4juUrPiMNQwseGA=
X-Google-Smtp-Source: ABhQp+Rf96emCbRuiovcT/kn45ov8Ok9ZTMqKHjp5kabkphqvylklaaJXM7dV+Rdr9dzaKPD9pBXByouoWd8BSNUfPw=
X-Received: by 10.28.18.144 with SMTP id 138mr1048508wms.135.1510166852819; Wed, 08 Nov 2017 10:47:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.150.10 with HTTP; Wed, 8 Nov 2017 10:47:32 -0800 (PST)
In-Reply-To: <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>
From: Alia Atlas 
Date: Wed, 8 Nov 2017 13:47:32 -0500
Message-ID: 
To: Ted Lemon 
Cc: james woodyatt , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= ,  Denis Ovsienko , Babel at IETF , Juliusz Chroboczek 
Content-Type: multipart/alternative; boundary="001a114732dcd05dee055d7d1e41"
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 08 Nov 2017 18:47:38 -0000

--001a114732dcd05dee055d7d1e41
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon  wrote:

> On Nov 8, 2017, at 8:40 PM, Alia Atlas  wrote:
>
> I strongly agree.  At least a mandatory-to-implement hop-to-hop security
> mechanism and what attacks it protects against is critical.
>
>
> A security model that protects against _anything_ requires it to actually
> be secure.   The current draft has no such mechanism.   So if you want to
> make something MTI, we can't do it with the current draft, or we'd be
> requiring people to implement mickey-mouse security.
>

Requiring a transport security isn't feasible?

A new routing protocol without solid security is not going to progress
successfully.

--001a114732dcd05dee055d7d1e41
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On W=
ed, Nov 8, 2017 at 1:42 PM, Ted Lemon <mellon@fugue.com> wrot=
e:
On Nov 8, 2017, at 8:40 PM, Alia Atlas <akatlas@gmail.com> wrote:
=

I strongly agree.=C2=A0 At least a mandatory=
-to-implement hop-to-hop security mechanism and what attacks it protects ag=
ainst is critical.

A security=
 model that protects against _anything_ requires it to actually be secure. =
=C2=A0 The current draft has no such mechanism. =C2=A0 So if you want to ma=
ke something MTI, we can't do it with the current draft, or we'd be=
 requiring people to implement mickey-mouse security.

Requiring a transport security isn't feasible?

A new routing protocol without solid security is no=
t going to progress successfully.=C2=A0



--001a114732dcd05dee055d7d1e41--


From nobody Wed Nov  8 10:57:03 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28880129B01 for ; Wed,  8 Nov 2017 10:57:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARwk6r-uoTaR for ; Wed,  8 Nov 2017 10:57:00 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 2FC70129B14 for ; Wed,  8 Nov 2017 10:56:59 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id c3so8109942itc.3 for ; Wed, 08 Nov 2017 10:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s1CazASYimj3XRf60qwnKsJEf0RQ7oQ1ccJA47ioOVg=; b=bN9Xqt+1UVsUHPzHf5ZXc16bLKxPdTgJvYuoMmgDXdkND5S4ALp2GKwacf2s8xA7QW NIdWxZT7GbpJABbKxDLYZioY9UI58ZrgcAjTAmV+jqayKQbz9QsEqauDKiZv2oar9eBj CxiAlggTSEovhMhKZfplDojloDTtV0HVKXhzqYCRq0hd3MlIE8TtXj/CHt1xz30UaJXD p3se1ab3lAO9t0vHOqgeVvh+HsnQkeZG98AU9tls+mFfQ4nuyPYNEbYhaqRP1j7b0dnb kbdnM5Wc5wgQ34ACHB2mf7CO4E9dtrEkaJbdDCWdE9tpEGp6A5c72bpShHN6hnctHPqH BbBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s1CazASYimj3XRf60qwnKsJEf0RQ7oQ1ccJA47ioOVg=; b=S6Vaqsa1+mEX7YjymNwLlPHuBIqUs0mS8Jf1zQWy5LvTfyY1EZGrJwh+b+sYv9P5hO Q0jy8GXA0NzSkcKF1CeZ9X8gAcnLSbox0q2S2OouAY/7R3CJ2ISjUK+oemUYrl+YNOcM aApJrNrkdYcHR6uiK2yW7an71HwSO+Ww6aBmH9PioYaoCgXvlKVECCfod9unA7kguMmk TWNeXt5TMjug9Gu+gHdc5WXip8diL01KsXVUeLu9pqzQqrVzrHiHHLGka0VTGUQ5GIhb AcLfCIrAVyOmYvlS19SfzMHC2udWHDLiNgjMzTHjPqR7tYUFYaCU5kQp+x4IWLOwzwsz K6rw==
X-Gm-Message-State: AJaThX7/zZt91//1490pZef61BaXom8o8AX1ucudv+v8Q15RbnmT9PTF N2t5XcX3biVJFFy/TA5p+Owyadg4LeP3QwQfARFmQg==
X-Google-Smtp-Source: ABhQp+T7KhpmzrpR+mgsxVZtjmDJj56ORSaVZOD1Yf+cBXgN8iyiAwNCl/bQ3YRo+5xK6a9nCmfqcTGHRMaeuZvW/5g=
X-Received: by 10.36.185.21 with SMTP id w21mr2132760ite.35.1510167418390; Wed, 08 Nov 2017 10:56:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.15.203 with HTTP; Wed, 8 Nov 2017 10:56:57 -0800 (PST)
Received: by 10.79.15.203 with HTTP; Wed, 8 Nov 2017 10:56:57 -0800 (PST)
In-Reply-To: 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com> 
From: Ted Lemon 
Date: Wed, 8 Nov 2017 13:56:57 -0500
Message-ID: 
To: Alia Atlas 
Cc: james woodyatt , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= ,  Denis Ovsienko , Babel at IETF , Juliusz Chroboczek 
Content-Type: multipart/alternative; boundary="f403045d9c20865ca2055d7d407c"
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 08 Nov 2017 18:57:02 -0000

--f403045d9c20865ca2055d7d407c
Content-Type: text/plain; charset="UTF-8"

I didn't say it wasn't feasible. I said it's not in this document. :)

On Nov 8, 2017 20:47, "Alia Atlas"  wrote:

> On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon  wrote:
>
>> On Nov 8, 2017, at 8:40 PM, Alia Atlas  wrote:
>>
>> I strongly agree.  At least a mandatory-to-implement hop-to-hop security
>> mechanism and what attacks it protects against is critical.
>>
>>
>> A security model that protects against _anything_ requires it to actually
>> be secure.   The current draft has no such mechanism.   So if you want to
>> make something MTI, we can't do it with the current draft, or we'd be
>> requiring people to implement mickey-mouse security.
>>
>
> Requiring a transport security isn't feasible?
>
> A new routing protocol without solid security is not going to progress
> successfully.
>
>

--f403045d9c20865ca2055d7d407c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I didn't say it wasn't feasible. I said it's =
not in this document. :)

On Nov 8, 2017 20:47, "Alia Atlas" <akatlas@gmail.com> wrote:
On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon =
<mellon@fugue.com> wrote:
<=
div style=3D"word-wrap:break-word">On Nov 8, 2017, at 8:40 PM, Alia A=
tlas <akatlas@gma=
il.com> wrote:
I strongly agree.=
=C2=A0 At least a mandatory-to-implement hop-to-hop security mechanism and =
what attacks it protects against is critical.

A security model that protects against _anything_ requires=
 it to actually be secure. =C2=A0 The current draft has no such mechanism. =
=C2=A0 So if you want to make something MTI, we can't do it with the cu=
rrent draft, or we'd be requiring people to implement mickey-mouse secu=
rity.

Requiring a transport sec=
urity isn't feasible?

A new routing protocol w=
ithout solid security is not going to progress successfully.=C2=A0





--f403045d9c20865ca2055d7d407c--


From nobody Wed Nov  8 11:10:50 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E1E129B51 for ; Wed,  8 Nov 2017 11:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDPvtk1Z84BB for ; Wed,  8 Nov 2017 11:10:40 -0800 (PST)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 978AC129B53 for ; Wed,  8 Nov 2017 11:10:39 -0800 (PST)
Received: by mail-pg0-x231.google.com with SMTP id s75so2642275pgs.0 for ; Wed, 08 Nov 2017 11:10:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wNyjHZnGrpv/gpQ2uc+HtBpvoYcIn14LpdCKLSIZL2A=; b=m7+BkyNcEgmPB7w/4xfCZwAcjH7+w1vkJe9fhRv1QOKHYY8CPJeBwD647RKBcdamIs 3ytRYIjVyOn5IAy8IwHrn7N2TfWoFxoqlxqCetDBK9IGVKxc8EzGLlGndHIHpqkyNjQD iy7gEWcxRBQxqd/cIxDGAq3l8iriU0+e9zzM06Y9QrPGYbGFUc47S/Iy0E2Z80T88ews JG8SrCVOdpF2Mlv4Ad+VHICMsCgpQKU4TqlVvD/jNq5Q//eqvwn4HqmrrrlYjo3u4j2z R3lLSX6GYWaHZN5SRV88iqAMCVRwkS4r/+XbKr6Qlx1KHMPxYywS0qfyPJOA1sRX4avh puQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wNyjHZnGrpv/gpQ2uc+HtBpvoYcIn14LpdCKLSIZL2A=; b=D1FoEi1xR+mqy+6JbSjh9WLWYJymWbYQGifFp1TNHlk7EoI0wD46DJqwH8tYQXk1TT jMA9VOS9C+uM3JPbepjMnS5uqrAkeP1x746rWT6LYb6O8jf0E/zDPSyDMSbvhwiatBCk fmCbx8gB/rVF8zEAyKA6OxU1hL5ONmZUpUrc3VxTUoV4L1aaO2J/whL5dmULw8mYbLTL JMx1eOSAkjVOJrGs+I3mJYLExlwewi7+U/X/36FkdHsdIWhTYL5UH0Deo8dSRJK57oOi rQA1J95fEkDGcKHvS5V38j7MSkRpp9WYl/oGQwgaalWecFu0xum9zZfFWTg26NQ0TiwT PRaQ==
X-Gm-Message-State: AJaThX44BgxuU/kWGNUwOjCeI6Y/4k6SzOo15sv3/Dbdzdpt0O6ixKoD HZxGXfvBGQjWUhZhfIE9/5TDmdtMtGk=
X-Google-Smtp-Source: ABhQp+RR0nHauu0OzgddYHjRAP7h2/f6IRzI+4z8KfAyJbKXkeln9Tnr6UmDo/zNbzpJli1zPZsmvQ==
X-Received: by 10.84.168.101 with SMTP id e92mr1367561plb.128.1510168238872; Wed, 08 Nov 2017 11:10:38 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:a7:873a:8815:2067? ([2620:0:10e7:10:a7:873a:8815:2067]) by smtp.gmail.com with ESMTPSA id y5sm9287463pfk.3.2017.11.08.11.10.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 11:10:38 -0800 (PST)
From: james woodyatt 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D82FB57-67E2-4B86-9BAB-B6980F482F96"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 8 Nov 2017 11:10:41 -0800
In-Reply-To: 
Cc: Ted Lemon , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Denis Ovsienko , Babel at IETF , Juliusz Chroboczek 
To: Alia Atlas 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 08 Nov 2017 19:10:49 -0000

--Apple-Mail=_4D82FB57-67E2-4B86-9BAB-B6980F482F96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 8, 2017, at 10:47, Alia Atlas  wrote:
> On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon > wrote:
> On Nov 8, 2017, at 8:40 PM, Alia Atlas > wrote:
>> I strongly agree.  At least a mandatory-to-implement hop-to-hop =
security mechanism and what attacks it protects against is critical.
>=20
> A security model that protects against _anything_ requires it to =
actually be secure.   The current draft has no such mechanism.   So if =
you want to make something MTI, we can't do it with the current draft, =
or we'd be requiring people to implement mickey-mouse security.
>=20
> Requiring a transport security isn't feasible?
>=20
> A new routing protocol without solid security is not going to progress =
successfully.=20

I think the compromise I was proposing is that RFC6126bis could be =
published with a =E2=80=9Cstrong admonition=E2=80=9D in its Security =
Considerations section that various security vulnerabilities are =
available unless an appropriate hop-by-hop security layer according to =
the deployment model is also used in conjunction with RFC 6126bis. I =
suspect the Working Group would prefer this instead of actually =
specifying and requiring a mandatory-to-implement security layer =
suitable for all deployment models. You=E2=80=99re saying the Working =
Group is going to lose that argument.

Having a procedural requirement to establish a tight coupling between =
the routing protocol and its universal and integrated security layer for =
Babel to progress successfully is a good thing to have aired before the =
end of Working Group Last Call.


--james woodyatt >




--Apple-Mail=_4D82FB57-67E2-4B86-9BAB-B6980F482F96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 8, 2017, at 10:47, Alia Atlas <akatlas@gmail.com> =
wrote:
On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon <mellon@fugue.com> wrote:
On Nov 8, =
2017, at 8:40 PM, Alia Atlas <akatlas@gmail.com> wrote:
I strongly agree.  At least a mandatory-to-implement =
hop-to-hop security mechanism and what attacks it protects against is =
critical.

A security model that protects against _anything_ requires it =
to actually be secure.   The current draft has no such mechanism. =
  So if you want to make something MTI, we can't do it with the =
current draft, or we'd be requiring people to implement mickey-mouse =
security.

Requiring a transport security isn't =
feasible?

A =
new routing protocol without solid security is not going to progress =
successfully. 



I think the compromise I =
was proposing is that RFC6126bis could be published with a =E2=80=9Cstrong=
 admonition=E2=80=9D in its Security Considerations section that various =
security vulnerabilities are available unless an appropriate hop-by-hop =
security layer according to the deployment model is also used in =
conjunction with RFC 6126bis. I suspect the Working Group would prefer =
this instead of actually specifying and requiring a =
mandatory-to-implement security layer suitable for all deployment =
models. You=E2=80=99re saying the Working Group is going to lose that =
argument.

Having a procedural =
requirement to establish a tight coupling between the routing protocol =
and its universal and integrated security layer for Babel to progress =
successfully is a good thing to have aired before the end of Working =
Group Last Call.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_4D82FB57-67E2-4B86-9BAB-B6980F482F96--


From nobody Wed Nov  8 11:26:02 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B1E129B56 for ; Wed,  8 Nov 2017 11:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93_AKgc_Om6P for ; Wed,  8 Nov 2017 11:25:59 -0800 (PST)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 D6778129B57 for ; Wed,  8 Nov 2017 11:25:57 -0800 (PST)
Received: by mail-wr0-x22e.google.com with SMTP id l22so3420066wrc.11 for ; Wed, 08 Nov 2017 11:25:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kbYHv+0B5QlRM3dGdXqf+IWk1eeZdgkYiw5aAnXTCIA=; b=Ay1BcGGDeGEqhaC6PoGnu2JXR/WR8wyAJB8Vfb9y5s314BL/pzUDrk9MPvCE8Vyool gnHt+29+y613wV7GEixvBWcM/7LwnkJTiLhCO3w996iHiK/tJDLRFZoyrVI77AXOoIil uIHJ2kCBjrWQNBDYUF+qCs2GRJeCI7TY8zvPV+z52AaAD2JxdlJTjLLrGm8yuv05Ck0p 6087YvZnlFMi9Fxhir44sHiGhPhg/wasBKQeFx+xghAfgfqq62y7ePMQ5fmtfdWhDUPs HNcYA/fifOspU/ja6/VPugIy168qQNBEdUlP3+p6ERXI7hRu3rsqGJHL0MFwGmAiMtl4 lEbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kbYHv+0B5QlRM3dGdXqf+IWk1eeZdgkYiw5aAnXTCIA=; b=rnSqDPWkzJegNqA7dnigSgmIjj+ZGG0VdL0x6rAP1pqB2raazIfD4l3YZ5tT3uqT9A S/mFjPMSbjHXQQNmpbahtcS5C8l2IUdPVpjHfageUDm+qjBtWU0Exn6AKdxLJIFlHJrC /AmOUag6mAlB+jOcjqr2XICCw4as3MrUHVKa6hoLlWc892oRaXDj5/WUDQqY7bXEoNyT /Bkztcl/hviSBMhGy5DQVrI3txD43+VlltfqTpQlITAYqQiQW194cF8hhF4CY6OG9D5R RysjpJT9EjzolPyd1NsRyRDLS54uLM1cQ6UclW7RN2Ld/ViTwLyiY9dD1gUiEEqzfYir VtMg==
X-Gm-Message-State: AJaThX42YFg+FYBLtPCcSxfo3NkGC40+tTygBRy7s33AIYzd8pH1lK7v 8ShEXvmbvjcikjZBbRUR1Xgsu2lz4yNaLWM879M=
X-Google-Smtp-Source: ABhQp+SnegDTDpuSHo0ew0YxoAk/y8/o2z8krkspPZNOmlB+heGAnh55xFpVvkRBLJByvJdNdU2lFVZ+oGmgOYq9OCg=
X-Received: by 10.223.199.138 with SMTP id l10mr1281208wrg.121.1510169156144;  Wed, 08 Nov 2017 11:25:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.150.10 with HTTP; Wed, 8 Nov 2017 11:25:55 -0800 (PST)
In-Reply-To: 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>  
From: Alia Atlas 
Date: Wed, 8 Nov 2017 14:25:55 -0500
Message-ID: 
To: james woodyatt , Kathleen Moriarty ,  Eric Rescorla 
Cc: Ted Lemon , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= ,  Denis Ovsienko , Babel at IETF , Juliusz Chroboczek 
Content-Type: multipart/alternative; boundary="089e0820dd101a53be055d7da85f"
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 08 Nov 2017 19:26:01 -0000

--089e0820dd101a53be055d7da85f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi James,

On Wed, Nov 8, 2017 at 2:10 PM, james woodyatt  wrote:

> On Nov 8, 2017, at 10:47, Alia Atlas  wrote:
>
> On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon  wrote:
>
>> On Nov 8, 2017, at 8:40 PM, Alia Atlas  wrote:
>>
>> I strongly agree.  At least a mandatory-to-implement hop-to-hop security
>> mechanism and what attacks it protects against is critical.
>>
>>
>> A security model that protects against _anything_ requires it to actuall=
y
>> be secure.   The current draft has no such mechanism.   So if you want t=
o
>> make something MTI, we can't do it with the current draft, or we'd be
>> requiring people to implement mickey-mouse security.
>>
>
> Requiring a transport security isn't feasible?
>
> A new routing protocol without solid security is not going to progress
> successfully.
>
>
> I think the compromise I was proposing is that RFC6126bis could be
> published with a =E2=80=9Cstrong admonition=E2=80=9D in its Security Cons=
iderations section
> that various security vulnerabilities are available unless an appropriate
> hop-by-hop security layer according to the deployment model is also used =
in
> conjunction with RFC 6126bis. I suspect the Working Group would prefer th=
is
> instead of actually specifying and requiring a mandatory-to-implement
> security layer suitable for all deployment models. You=E2=80=99re saying =
the
> Working Group is going to lose that argument.
>
> Having a procedural requirement to establish a tight coupling between the
> routing protocol and its universal and integrated security layer for Babe=
l
> to progress successfully is a good thing to have aired before the end of
> Working Group Last Call.
>

 Let me add in Kathleen and Eric here as well.

I have to take a read through the updated draft myself, but I can see no
reason to not adequately address control-plane security in
a new routing protocol when it is moving to the Standards track.  Making
sure that security is adequately addressed is one of the
attributes that we look for in standards track work.

The charter does say "Particular emphasis will be placed on work needed
for a Proposed Standard routing protocol, such as ensuring manageability
and strong security."  and among the Work Items are:

" Address security needs for BABEL. This may include using the
techniques in RFC 7298, or other alternatives. Security may be
included in the base spec or the base spec may normatively reference a
separate Proposed Standard specification. This is required as part of
moving Babel to Proposed Standard."

I am very pleased with the work and discussion so far on clarifying and
improving Babel.
This aspect is also critical.

Regards,
Alia

--089e0820dd101a53be055d7da85f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi James,

On Wed, Nov 8, 2017 at 2:10 PM, james woodyatt &=
lt;jhw@google.com&g=
t; wrote:
On Nov 8, 2017,=
 at 10:47, Alia Atlas <akatlas@gmail.com> wrote:
<=
div dir=3D"ltr">
On We=
d, Nov 8, 2017 at 1:42 PM, Ted Lemon <mellon@fugue.com> wrote=
:
On Nov 8, 2017, at 8:40 PM, Alia Atlas <akatlas@gmail.com> wrot=
e:
I strongly agree.=C2=A0 At least a ma=
ndatory-to-implement hop-to-hop security mechanism and what attacks it prot=
ects against is critical.

A s=
ecurity model that protects against _anything_ requires it to actually be s=
ecure. =C2=A0 The current draft has no such mechanism. =C2=A0 So if you wan=
t to make something MTI, we can't do it with the current draft, or we&#=
39;d be requiring people to implement mickey-mouse security.

Requiring a transport security isn't feas=
ible?

A new routing protocol without solid securit=
y is not going to progress successfully.=C2=A0



I think the compromise I was =
proposing is that RFC6126bis could be published with a =E2=80=9Cstrong admo=
nition=E2=80=9D in its Security Considerations section that various securit=
y vulnerabilities are available unless an appropriate hop-by-hop security l=
ayer according to the deployment model is also used in conjunction with RFC=
 6126bis. I suspect the Working Group would prefer this instead of actually=
 specifying and requiring a mandatory-to-implement security layer suitable =
for all deployment models. You=E2=80=99re saying the Working Group is going=
 to lose that argument.

Having a procedural requir=
ement to establish a tight coupling between the routing protocol and its un=
iversal and integrated security layer for Babel to progress successfully is=
 a good thing to have aired before the end of Working Group Last Call.

=C2=A0Let me add in Kathleen and Er=
ic here as well.

I have to take a read through the=
 updated draft myself, but I can see no reason to not adequately address co=
ntrol-plane security in
a new routing protocol when it is moving =
to the Standards track.=C2=A0 Making sure that security is adequately addre=
ssed is one of the
attributes that we look for in standards track=
 work.

The charter does say "Particular emphasis will be placed on work needed=C2=A0
for a Prop=
osed Standard routing protocol, such as ensuring manageability=C2=A0=

a=
nd strong security."=C2=A0 and among the Work Items are:
<=
div class=3D"gmail_quote">
"=C2=A0Address security ne=
eds for BABEL. This may include using the
techniques in RFC 7298, or other alternatives. Security may be=

i=
ncluded in the base spec or the base spec may normatively reference a
=
separate Proposed Standard specification. This is required as part of
=
moving Babel to Proposed Standard."

I=
 am very pleased with the work and discussion so far on clarifying and impr=
oving Babel.
This as=
pect is also critical.

Regards,
Alia
<=
div class=3D"gmail_quote">



--089e0820dd101a53be055d7da85f--


From nobody Wed Nov  8 16:19:25 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B956B129421; Wed,  8 Nov 2017 16:19:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eNTIK_UvKjz; Wed,  8 Nov 2017 16:19:21 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5686012778E; Wed,  8 Nov 2017 16:19:21 -0800 (PST)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1510186752; bh=y0xkGrNDrHtWAGuQnmpUWCWdoRm+uU24ZTLx12Gy1oI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MPAcVpVw45qf2BYcXx6LyBLQvbM7YguXAeZf9dYoxgL7ejk2Qiu5pii8fD0ahefZo Syzw4HcFZGmOVbLVIRTdaWoClnBvF07PHkhTOna9045yGOAKxXeDM+syKOeJA519ww wMYwpjMBYJSM+YCV4xb6GwegVPjlwnqOQwZWfZCcGrUwO7WVhmESeyPXYliA8DUYnH gAtwOShJiRxVE7fuJv88KNL4nHJmvO611AgDFfGY+7SojPU2UctG8eCNE3Kdc5ZDCB 5aLOO//5Ld+4+FRlgK3ceh1tpyDXVQNfdeFympgRZ3NIfy6IdeNkiwyT+wNN7buv7x b0myW+xkRekww==
To: Matthieu Boutier , Joel Halpern 
Cc: rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org
In-Reply-To: <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr>
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr>
Date: Thu, 09 Nov 2017 09:18:55 +0900
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87po8sqp74.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 00:19:22 -0000

Matthieu Boutier  writes:

> Hi,
>
> Thank's a lot for this early review.
>
>> Please address the issues reported by id-nits.
>
> Please accept my apologizes about these nits.
>
>> The base Babel (bis) specification does not talk about the handling of
>> duplicate sub-TLVs.  Are multiple source-specific sub-TLVs allowed on a given
>> destination prefix advertisement?
>
> I believe it is clear that a Babel node MUST NOT send two Source Prefix sub-TLVs
> in one TLV.  But If a received TLV has two Source Prefix sub-TLVs, I hesitate:
> does a node SHOULD or MUST ignore the whole TLV?
>
> Does the list have an opinion?

Off the top of my head: Ignore the whole thing; better to fail
(preferably loudly) than carry on with ambiguous semantics.

-Toke


From nobody Wed Nov  8 16:44:57 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221DB12941D for ; Wed,  8 Nov 2017 16:44:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 a2zTK3t-4GbP for ; Wed,  8 Nov 2017 16:44:51 -0800 (PST)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 A2590129454 for ; Wed,  8 Nov 2017 16:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510188289; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uoHAtRgbWJpUOlYhbuEM5j8vmvFFzCvqYFzjmPssmwI=; b=KwHvz1KScC31EpXBs4qsXPNTpJd2vRSVuYICQ1I0SkW1MMugXviq4ZODPzAXG2WH yY4MO5gMjbKV77CwwDgh9V/ST56wc3GPoGMGMbkJwEWhr5Ntfz737eIiZ9r11APL cD2vLjR6XoGwIUVwbti269esjlVeTrt0qpB7w0mdZuuvHBPYTi7WKSEKv1Sue8Dl Fe5U9ftWBh3lopkKAlahHtoM5MACPIyPDapdRs3JE2w0UMGSpeO7CANW9GsUuwXP 7We+9ve4eWJ5iM43uv4ZFgpVMVXBDWsamFVtbZdY2FjsaHRshMxt2zruu0lsofyJ v6Ymrnyr2SAcuZ9AbUi4ig==;
Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id CC.80.16042.105A30A5; Wed,  8 Nov 2017 16:44:49 -0800 (PST)
X-AuditID: 11973e12-355ff70000003eaa-85-5a03a501192d
Received: from jimbu.apple.com (jimbu.apple.com [17.151.62.37]) by relay3.apple.com (Apple SCV relay) with SMTP id C5.FC.23978.105A30A5; Wed,  8 Nov 2017 16:44:49 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)"
Received: from [17.226.23.83] (unknown [17.226.23.83]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZ4004A9KQONI30@jimbu.apple.com>;  Wed, 08 Nov 2017 16:44:48 -0800 (PST)
Sender: dschinazi@apple.com
From: David Schinazi 
Message-id: <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com>
Date: Wed, 08 Nov 2017 16:44:48 -0800
In-reply-to: <87po8sqp74.fsf@toke.dk>
Cc: Matthieu Boutier , Joel Halpern , rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org
To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= 
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk>
X-Mailer: Apple Mail (2.3445.1.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUi2FAYrMu4lDnK4PMKUYsti7pZLA5/aWSx eLbzJavFx1NvmCwWrHnKbrH1/Qp2BzaPJUt+Mnks3vKW0ePclO+MHlsOXWQLYInisklJzcks Sy3St0vgytj1ZQp7wYHYikvf5jE1MD4M7GLk5JAQMJE4t/I8WxcjF4eQwGomiUt/pjLBJBp6 DzBBJDYwSkx4vY4dJMErICjxY/I9FhCbWSBM4sfVq2C2kMBfRokZjeUgtrCAtETXhbusXYwc HGwCWhIH1hhBtNpIzD36kh2ixF/iwcupYK0sAqoS616eYwOxOYHsxVumMILsZRaYyyhxc/5q sAYRAXuJxq8XWCAO6mWUaPu9lQXiUkWJIzPnMIMkJAROsEm0HZzAPIFRaBaSY2chOXYW0FHM AuoSU6bkQoS1JZ68u8AKYatJLPy9iAlZfAEj2ypGodzEzBzdzDwTvcSCgpxUveT83E2MoEia bie0g/HUKqtDjAIcjEo8vBqKTFFCrIllxZW5hxilOViUxHlTXzFECQmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamD0DnZIWh4l+2zOJr3Pr3xu6Phbuc283D3Fduujx0f+/gx9pfou18ghWbir wX3CjCwV5XfJe6Mcn2t0hE7k6pz/yNuqM//ScTflliCx1spZFU9D/+TXNaVpH3lj9jRUtXDn 17f2lecLp7+ukP35RTr6Bdsr1akRhxjSlJ7v4p+VWPS4KIGJf64SS3FGoqEWc1FxIgBZXjj6 hQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUiON1OVZdxKXOUwY5lghZbFnWzWBz+0shi 8WznS1aLj6feMFksWPOU3WLr+xXsDmweS5b8ZPJYvOUto8e5Kd8ZPbYcusgWwBLFZZOSmpNZ llqkb5fAlbHryxT2ggOxFZe+zWNqYHwY2MXIySEhYCLR0HuAqYuRi0NIYAOjxITX69hBErwC ghI/Jt9jAbGZBcIkfly9CmYLCfxllJjRWA5iCwtIS3RduMvaxcjBwSagJXFgjRFEq43E3KMv 2SFK/CUevJwK1soioCqx7uU5NhCbE8hevGUKI8heZoG5jBI3568GaxARsJdo/HqBBeKgXkaJ tt9bWSAuVZQ4MnMO8wRG/llI7puF5L5ZQHcwC6hLTJmSCxHWlnjy7gIrhK0msfD3IiZk8QWM bKsYBYpScxIrjfUSCwpyUvWS83M3MYICv6EweAfjn2VWhxgFOBiVeHgvyDFFCbEmlhVX5h5i lOBgVhLhtc5kjhLiTUmsrEotyo8vKs1JLT7EKM3BoiTO25HBECUkkJ5YkpqdmlqQWgSTZeLg lGpg3BbLtqu28qty6YQche5I4/Pbp+ydPe9Kx/O6+SdOTNq1PWpynpBK8oE1Oa0ueY/D4+cZ nzh1dwkvw+YZnNIiCxiMVdsqG3+eXXffW3xJ8UK116dmmG+dVJ3CXSv4UGiWwe8Ll/9NbjbP 1BfK1zaY8i57X0G2u+hqrbIoxh8XZSZ+LD275rXlNiWW4oxEQy3mouJEAOE6OYh4AgAA
Archived-At: 
Subject: Re: [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 00:44:53 -0000

--Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

$.02

Personally, if I receive something that the spec says you MUST NOT do I =
get upset at the packet.
Maybe I ignore the whole TLV, maybe the whole packet, maybe I summon the =
wrath of the Gods of the Internet.
If you expect that someone someday could find a use case for sending two =
sub-TLVs,
then I'd recommend explicitly saying MUST NOT send and on receive MUST =
drop TLV but not packet.
If you don't expect this to ever be useful, no need to specify it.

David


> On Nov 8, 2017, at 16:18, Toke H=C3=B8iland-J=C3=B8rgensen =
 wrote:
>=20
> Matthieu Boutier > writes:
>=20
>> Hi,
>>=20
>> Thank's a lot for this early review.
>>=20
>>> Please address the issues reported by id-nits.
>>=20
>> Please accept my apologizes about these nits.
>>=20
>>> The base Babel (bis) specification does not talk about the handling =
of
>>> duplicate sub-TLVs.  Are multiple source-specific sub-TLVs allowed =
on a given
>>> destination prefix advertisement?
>>=20
>> I believe it is clear that a Babel node MUST NOT send two Source =
Prefix sub-TLVs
>> in one TLV.  But If a received TLV has two Source Prefix sub-TLVs, I =
hesitate:
>> does a node SHOULD or MUST ignore the whole TLV?
>>=20
>> Does the list have an opinion?
>=20
> Off the top of my head: Ignore the whole thing; better to fail
> (preferably loudly) than carry on with ambiguous semantics.
>=20
> -Toke
>=20
> _______________________________________________
> babel mailing list
> babel@ietf.org 
> https://www.ietf.org/mailman/listinfo/babel =


--Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable

$.02

Personally, if I receive something that the spec says you =
MUST NOT do I get upset at the packet.
Maybe I ignore the =
whole TLV, maybe the whole packet, maybe I summon the wrath of the Gods =
of the Internet.
If you expect that =
someone someday could find a use case for sending two =
sub-TLVs,
then I'd recommend explicitly saying MUST =
NOT send and on receive MUST drop TLV but not packet.
If you don't expect this to ever be useful, no need to =
specify it.

David


On Nov =
8, 2017, at 16:18, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> =
wrote:

Matthieu Boutier <boutier@irif.fr> writes:
Hi,

Thank's a lot for this early review.

Please address the =
issues reported by id-nits.

Please accept my apologizes about these nits.
The base Babel (bis) =
specification does not talk about the handling of
duplicate =
sub-TLVs.  Are multiple source-specific sub-TLVs allowed on a =
given
destination prefix advertisement?

I believe it is clear that a =
Babel node MUST NOT send two Source Prefix sub-TLVs
in one =
TLV.  But If a received TLV has two Source Prefix sub-TLVs, I =
hesitate:
does a node SHOULD or MUST ignore the whole =
TLV?

Does the list have an opinion?

Off the top of my head: Ignore the whole =
thing; better to fail
(preferably loudly) than carry =
on with ambiguous semantics.

-Toke

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

=

--Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)--


From nobody Wed Nov  8 17:44:52 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BBF12957C for ; Wed,  8 Nov 2017 17:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=apple.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 qKKJtzhj9enR for ; Wed,  8 Nov 2017 17:44:50 -0800 (PST)
Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 C89A012955A for ; Wed,  8 Nov 2017 17:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510191888; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2KwXidv6IlsDLg/vEsmiI0A5tDBNpjkpNGMZEghKFzk=; b=R9IyYtyET+lbt+Mulqo4Aon8WN/fXLCQSP1gBq4IWjNsi47nBMIrAPvuFFNaeVqb uSUt23exRK/32UK5KZTgjHECr5bzKeiuUitI7CPi9Ph3t872hb61bp/hVIPK4sOP EbSEbMUqskmqysW4tUXJkQlggDI0E3BRMfySiqkCju0uxd8FcZKuowfpug7LAy8d k5HtTvOPIQawDxgt9ZuTPlUrvE00eLGcK95sySaMUI1udSB4uxcQO3qe0BcNL0Lj CSOaydeDqoTtAJUrojubtnh4gPJ9eCJESeVl35OyL2ZjFuOcglr8HZ2AVmrWv1eo SQDBWpPdytXKHMI/rXFjig==;
Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 66.D9.08992.013B30A5; Wed,  8 Nov 2017 17:44:48 -0800 (PST)
X-AuditID: 11ab0216-43acf9c000002320-27-5a03b3109d55
Received: from kencur.apple.com (kencur.apple.com [17.151.62.38]) by relay2.apple.com (Apple SCV relay) with SMTP id 96.92.21963.F03B30A5; Wed,  8 Nov 2017 17:44:48 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_6rhjNpGQdBD01Bd+BYr3xQ)"
Received: from [17.234.10.143] (unknown [17.234.10.143]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZ4007X2NIJJE20@kencur.apple.com>; Wed, 08 Nov 2017 17:44:47 -0800 (PST)
Sender: dschinazi@apple.com
From: David Schinazi 
Message-id: 
Date: Wed, 08 Nov 2017 17:44:41 -0800
In-reply-to: 
Cc: james woodyatt , Kathleen Moriarty , Eric Rescorla , Denis Ovsienko , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Ted Lemon , Juliusz Chroboczek , Babel at IETF 
To: Alia Atlas 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>   
X-Mailer: Apple Mail (2.3445.1.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUi2FDorCuwmTnK4MoSK4tPDy8xW2xZ1M1i MefWdxaLFa/PsVvMb13GZvGz7RCzRcPOfIs3a44wWWx9v4LdgdOj6cIydo+ds+6yeyzYVOqx ZMlPJo/FW94yeqw4uZHNY/LjNmaPLYcusgVwRHHZpKTmZJalFunbJXBlrGs5yV7wu4mxYt6+ 34wNjF8Kuxg5OCQETCR6Z2V0MXJxCAmsYZJY/+IkaxcjJ1i8eX03C0RiE6NE57vzzCAJXgFB iR+T77GA2MwCYRJXV6xigyhqZpK4e3EjE0hCWEBaouvCXVaQDWwCWhIH1hhB9NpI7D/0gxGi JFJi9oQ2NhCbRUBVYtu9v2CtnALBElsvv2YCmckscIRJovtEIzPIHBEBJYmpL4Uhdi1nl1g9 9xUTxKWKEkdmzmGGsM+xS5y6bTWBUWgWkltnIbl1FtAoZgF1iSlTciHC2hJP3l1ghbDVJBb+ XsSELL6AkW0Vo3BuYmaObmaekZFeYkFBTqpecn7uJkZQLK5mEtvBeO+14SFGAQ5GJR7eF6uY o4RYE8uKK3MPMUpzsCiJ897e+jtSSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+OM3+092+Pn sgjPnnT8yQ9Xt+l9/e7R7G5rrGIzL5ct8099kWv5/Pm0NQWfo75wn9PS7vj6Zcfarz5tP8V6 TgUz8PjOW/Lw3GyWaot7lzKTty5ZsPY538QHTQlzuMob1lrwCFnPvVJ8kOHlp+chF8szv5ne LVyXVZ4sGjhNNXPPSaHiXRoXT9crsRRnJBpqMRcVJwIAfAZ9GKYCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUiON1OTVdgM3OUwd0VjBafHl5ittiyqJvF Ys6t7ywWK16fY7eY37qMzeJn2yFmi4ad+RZv1hxhstj6fgW7A6dH04Vl7B47Z91l91iwqdRj yZKfTB6Lt7xl9FhxciObx+THbcweWw5dZAvgiDK0ScsvKk8sSlEoSi4osVUqzkhMyS+PtzQ2 MnVILCjISdVLzs9V0rezSUnNySxLLdK3SzDMWNdykr3gdxNjxbx9vxkbGL8UdjFyckgImEg0 r+9m6WLk4hAS2MQo0fnuPDNIgldAUOLH5HssIDazQJjE1RWr2CCKmpkk7l7cyASSEBaQlui6 cJe1i5GDg01AS+LAGiOIXhuJ/Yd+MEKURErMntDGBmKzCKhKbLv3F6yVUyBYYuvl10wgM5kF jjBJdJ9oZAaZIyKgJDH1pTDEruXsEqvnvmKCuFRR4sjMOcwTGPlnIblvFpL7ZgG1MwuoS0yZ kgsR1pZ48u4CK4StJrHw9yImZPEFjGyrGAWKUnMSK4304MG2iREUiw2FzjsYjy2zOsQowMGo xMPrsJY5Sog1say4MvcQowQHs5IIb9MyoBBvSmJlVWpRfnxRaU5q8SFGH6AnJzJLiSbnA9NE Xkm8obGFsaWJhYGBiaWZCQ5hJXHejgyGKCGB9MSS1OzU1ILUIphxTBycUg2M3Wwi3K/0YqZ4 7dE4cZ/Br/Xl+7U/Jl8zdp2f05Eruqg9dsvF0xsrf2ezb9JJuz5Bw/rIgpdnXZLjnp83/Jrn eqbmwtmmO4U/nFsWS8o8jr/xxCpbWIRzmVrr/ZszetZMeHF4k/vy5BNrN0+tFlXWt/i+0OBK 37nJ+zUlJyou3rbDl8nuj4veFyUWYAIz1GIuKk4EAA+Ex+DyAgAA
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 01:44:52 -0000

--Boundary_(ID_6rhjNpGQdBD01Bd+BYr3xQ)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

Hi Alia,

I strongly believe the security should be decoupled from the routing =
protocol.
You could have a network where parts of it are using DTLS, parts use =
IPsec,
parts are in a bunker on the moon and rely on physical security.
Babel was designed to be used in heterogeneous networks.
While I suspect Juliusz originally meant Wi-Fi vs Ethernet, I think this =
key
principle of the protocol applies to local security properties as well.

Thanks,
David


> On Nov 8, 2017, at 11:25, Alia Atlas  wrote:
>=20
> Hi James,
>=20
> On Wed, Nov 8, 2017 at 2:10 PM, james woodyatt > wrote:
> On Nov 8, 2017, at 10:47, Alia Atlas > wrote:
>> On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon > wrote:
>> On Nov 8, 2017, at 8:40 PM, Alia Atlas > wrote:
>>> I strongly agree.  At least a mandatory-to-implement hop-to-hop =
security mechanism and what attacks it protects against is critical.
>>=20
>> A security model that protects against _anything_ requires it to =
actually be secure.   The current draft has no such mechanism.   So if =
you want to make something MTI, we can't do it with the current draft, =
or we'd be requiring people to implement mickey-mouse security.
>>=20
>> Requiring a transport security isn't feasible?
>>=20
>> A new routing protocol without solid security is not going to =
progress successfully.=20
>=20
> I think the compromise I was proposing is that RFC6126bis could be =
published with a =E2=80=9Cstrong admonition=E2=80=9D in its Security =
Considerations section that various security vulnerabilities are =
available unless an appropriate hop-by-hop security layer according to =
the deployment model is also used in conjunction with RFC 6126bis. I =
suspect the Working Group would prefer this instead of actually =
specifying and requiring a mandatory-to-implement security layer =
suitable for all deployment models. You=E2=80=99re saying the Working =
Group is going to lose that argument.
>=20
> Having a procedural requirement to establish a tight coupling between =
the routing protocol and its universal and integrated security layer for =
Babel to progress successfully is a good thing to have aired before the =
end of Working Group Last Call.
>=20
>  Let me add in Kathleen and Eric here as well.
>=20
> I have to take a read through the updated draft myself, but I can see =
no reason to not adequately address control-plane security in
> a new routing protocol when it is moving to the Standards track.  =
Making sure that security is adequately addressed is one of the
> attributes that we look for in standards track work.
>=20
> The charter does say "Particular emphasis will be placed on work =
needed=20
> for a Proposed Standard routing protocol, such as ensuring =
manageability=20
> and strong security."  and among the Work Items are:
>=20
> " Address security needs for BABEL. This may include using the
> techniques in RFC 7298, or other alternatives. Security may be
> included in the base spec or the base spec may normatively reference a
> separate Proposed Standard specification. This is required as part of
> moving Babel to Proposed Standard."
>=20
> I am very pleased with the work and discussion so far on clarifying =
and improving Babel.
> This aspect is also critical.
>=20
> Regards,
> Alia
>=20
> _______________________________________________
> babel mailing list
> babel@ietf.org 
> https://www.ietf.org/mailman/listinfo/babel =


--Boundary_(ID_6rhjNpGQdBD01Bd+BYr3xQ)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable

Hi =
Alia,

I strongly =
believe the security should be decoupled from the routing =
protocol.
You could have a network where parts of =
it are using DTLS, parts use IPsec,
parts are in a =
bunker on the moon and rely on physical security.
Babel was designed to be used in heterogeneous =
networks.
While I suspect Juliusz originally meant =
Wi-Fi vs Ethernet, I think this key
principle of =
the protocol applies to local security properties as well.

Thanks,
David


On Nov =
8, 2017, at 11:25, Alia Atlas <akatlas@gmail.com> wrote:

Hi =
James,

On Wed, Nov 8, 2017 at 2:10 PM, james =
woodyatt <jhw@google.com> wrote:
On Nov 8, 2017, at 10:47, Alia Atlas <akatlas@gmail.com> wrote:
On Wed, Nov 8, 2017 at =
1:42 PM, Ted Lemon <mellon@fugue.com> wrote:
On Nov 8, =
2017, at 8:40 PM, Alia Atlas <akatlas@gmail.com> wrote:
I strongly agree.  At least =
a mandatory-to-implement hop-to-hop security mechanism and what attacks =
it protects against is critical.

A security model that protects against =
_anything_ requires it to actually be secure.   The current draft =
has no such mechanism.   So if you want to make something MTI, we =
can't do it with the current draft, or we'd be requiring people to =
implement mickey-mouse security.

Requiring a transport =
security isn't feasible?

A new routing protocol without solid security is not going to =
progress =
successfully. 

I think the compromise I =
was proposing is that RFC6126bis could be published with a =E2=80=9Cstrong=
 admonition=E2=80=9D in its Security Considerations section that various =
security vulnerabilities are available unless an appropriate hop-by-hop =
security layer according to the deployment model is also used in =
conjunction with RFC 6126bis. I suspect the Working Group would prefer =
this instead of actually specifying and requiring a =
mandatory-to-implement security layer suitable for all deployment =
models. You=E2=80=99re saying the Working Group is going to lose that =
argument.

Having=
 a procedural requirement to establish a tight coupling between the =
routing protocol and its universal and integrated security layer for =
Babel to progress successfully is a good thing to have aired before the =
end of Working Group Last Call.

 Let me add in =
Kathleen and Eric here as well.

I have to take a read through the =
updated draft myself, but I can see no reason to not adequately address =
control-plane security in
a new routing protocol =
when it is moving to the Standards track.  Making sure that =
security is adequately addressed is one of the
attributes that we look for in standards track =
work.

The =
charter does say "Particular emphasis will be placed on work needed 
for a Proposed Standard =
routing protocol, such as ensuring manageability 
and strong =
security."  and among the Work Items are:

" Address security needs =
for BABEL. This may include using the
techniques in RFC 7298, =
or other alternatives. Security may be
included in the base =
spec or the base spec may normatively reference a
separate =
Proposed Standard specification. This is required as part of
moving Babel =
to Proposed Standard."

I am very pleased with the work and discussion so far =
on clarifying and improving Babel.
This =
aspect is also critical.

Regards,
Alia

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

=

--Boundary_(ID_6rhjNpGQdBD01Bd+BYr3xQ)--


From nobody Wed Nov  8 18:50:34 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0368B129B34 for ; Wed,  8 Nov 2017 18:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 L4zO6XARWuIx for ; Wed,  8 Nov 2017 18:50:29 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1F7129A9C for ; Wed,  8 Nov 2017 18:50:28 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id r68so14652968wmr.3 for ; Wed, 08 Nov 2017 18:50:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m1KTK5Wxvt+njHYXKf9sV15nan8w+b5vbLpiTt826Vc=; b=W591VhfDdxf0ARlv+Xd7vkzFLYEmjrJJYCTpMlwxNHxSFnRxN2jHlJ8oNtybe8INjo IZSaP8EyLQhRkdY9/5A64N3lQB2NvaE7WGw74dCh/YXiMpdMu13klYnP+bszOcNclXq8 vaah/hf/gkvLiL/2+zxa8d7YwWwj9JX781c2P/Zfur7SiUDJg0TvXokVWECYQOfaP3qi PLt6AbINbjU6i0VbGnBiMKEVY7P0RFhZjvc8XuFCEU5aqFxAC83EhD2jzVkyNwRCL1Mj yAH8A7dr7LFA+f2VntgduupEv663gl4d6gP7Sos5Wv3OcPVPJmWZlszQrrnvKlwQ7brR +mdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m1KTK5Wxvt+njHYXKf9sV15nan8w+b5vbLpiTt826Vc=; b=I9QGGl5OgOWsMwOsjnVEDh2IVnHP2pizwiUHyTC5ORA9nn71PpAfx+Y9Q52kbuDpUC bV6QaDvj4iuL+w/tyzclSRoD5aEdjOzVrubTNqjKximp8dP4eK4pQc2e/j6rri0DoELS NN1qz/5R3B07JCquxAAPQ5ZmxIsD9v8/Oqdn+OMU9gTDXGIs/pHYGZW6DdDm0uBMHyNT 1V5N3FGQJ3dI1tX2grn1S918h6thnoceiQqaiNm5a5+qbB4CwWEGjXuQXzWBr02VcWFp HtZX+d7u5wntr4Pidze5lG/Vjjt3KOyXwqZeKa0dVTlPSWsu7cZAQfLmwXAB3cnA9B7y UUrw==
X-Gm-Message-State: AJaThX7PRnvx8V/uOPILuVhQTb7bl97tE2HWFT9Tlgbx7ImWh6hgjUDC qTyaXZ3oRM6I02GLlxfmXidZlimWtV3fH2EQDtU=
X-Google-Smtp-Source: ABhQp+TjoHQ4oxGXcf39DDnf1IzIjoo+BtqR9GKBxkEKc8/soPldrNaQDcKfvztcq6ujIAMCROTSfqZw3kEO25CZr6Q=
X-Received: by 10.28.18.144 with SMTP id 138mr1646386wms.135.1510195827338; Wed, 08 Nov 2017 18:50:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.150.10 with HTTP; Wed, 8 Nov 2017 18:50:26 -0800 (PST)
In-Reply-To: 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>    
From: Alia Atlas 
Date: Wed, 8 Nov 2017 21:50:26 -0500
Message-ID: 
To: David Schinazi 
Cc: james woodyatt , Kathleen Moriarty ,  Eric Rescorla , Denis Ovsienko ,  =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= ,  Ted Lemon , Juliusz Chroboczek , Babel at IETF 
Content-Type: multipart/alternative; boundary="001a114732dcd472f4055d83ddd7"
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 02:50:32 -0000

--001a114732dcd472f4055d83ddd7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi David,

I do agree that flexibility is important. The logic behind having one
mandatory-to-implement
security mechanism is that the different implementations are able to
securely interoperate.
If one vendor implements DTLS and another does IPsec, then those two
vendors can't
interoperate securely - and since connectivity is almost always viewed as
more critical than
security, that is the one that gets tossed.

This is particularly important in a home environment, where one can't
assume a knowledgeable
operator and where it is more possible that private information may be
conveyed via route
information pertaining to individuals' personal equipment.

There are probably several different options - around what requires
integrity protection, what
needs confidentiality, what should be built in as a protocol extension
versus what can be used
at the transport layer.

I don't have any technical opinion or preference - but this needs to be
easy enough for a small
enterprise or home user to pull equipment from different vendors out of the
boxes over a period
of years - and have them work securely together.  I don't have solutions
for the keying issues -
or thoughts as to whether opportunistic encryption might be good in some
cases.

Regards,
Alia


On Wed, Nov 8, 2017 at 8:44 PM, David Schinazi  wrote:

> Hi Alia,
>
> I strongly believe the security should be decoupled from the routing
> protocol.
> You could have a network where parts of it are using DTLS, parts use IPse=
c,
> parts are in a bunker on the moon and rely on physical security.
> Babel was designed to be used in heterogeneous networks.
> While I suspect Juliusz originally meant Wi-Fi vs Ethernet, I think this
> key
> principle of the protocol applies to local security properties as well.
>
> Thanks,
> David
>
>
> On Nov 8, 2017, at 11:25, Alia Atlas  wrote:
>
> Hi James,
>
> On Wed, Nov 8, 2017 at 2:10 PM, james woodyatt  wrote:
>
>> On Nov 8, 2017, at 10:47, Alia Atlas  wrote:
>>
>> On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon  wrote:
>>
>>> On Nov 8, 2017, at 8:40 PM, Alia Atlas  wrote:
>>>
>>> I strongly agree.  At least a mandatory-to-implement hop-to-hop securit=
y
>>> mechanism and what attacks it protects against is critical.
>>>
>>>
>>> A security model that protects against _anything_ requires it to
>>> actually be secure.   The current draft has no such mechanism.   So if =
you
>>> want to make something MTI, we can't do it with the current draft, or w=
e'd
>>> be requiring people to implement mickey-mouse security.
>>>
>>
>> Requiring a transport security isn't feasible?
>>
>> A new routing protocol without solid security is not going to progress
>> successfully.
>>
>>
>> I think the compromise I was proposing is that RFC6126bis could be
>> published with a =E2=80=9Cstrong admonition=E2=80=9D in its Security Con=
siderations section
>> that various security vulnerabilities are available unless an appropriat=
e
>> hop-by-hop security layer according to the deployment model is also used=
 in
>> conjunction with RFC 6126bis. I suspect the Working Group would prefer t=
his
>> instead of actually specifying and requiring a mandatory-to-implement
>> security layer suitable for all deployment models. You=E2=80=99re saying=
 the
>> Working Group is going to lose that argument.
>>
>> Having a procedural requirement to establish a tight coupling between th=
e
>> routing protocol and its universal and integrated security layer for Bab=
el
>> to progress successfully is a good thing to have aired before the end of
>> Working Group Last Call.
>>
>
>  Let me add in Kathleen and Eric here as well.
>
> I have to take a read through the updated draft myself, but I can see no
> reason to not adequately address control-plane security in
> a new routing protocol when it is moving to the Standards track.  Making
> sure that security is adequately addressed is one of the
> attributes that we look for in standards track work.
>
> The charter does say "Particular emphasis will be placed on work needed
> for a Proposed Standard routing protocol, such as ensuring manageability
> and strong security."  and among the Work Items are:
>
> " Address security needs for BABEL. This may include using the
> techniques in RFC 7298, or other alternatives. Security may be
> included in the base spec or the base spec may normatively reference a
> separate Proposed Standard specification. This is required as part of
> moving Babel to Proposed Standard."
>
> I am very pleased with the work and discussion so far on clarifying and
> improving Babel.
> This aspect is also critical.
>
> Regards,
> Alia
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>
>
>

--001a114732dcd472f4055d83ddd7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi David,

I do agree that flexibility is important. The logic behind=
 having one mandatory-to-implement
security=
 mechanism is that the different implementations are able to securely inter=
operate.
If one vendor implements DTLS and =
another does IPsec, then those two vendors can't
interoperate securely - and since connectivity is almost always v=
iewed as more critical than
security, that =
is the one that gets tossed.

This is particularly important in a home environment=
, where one can't assume a knowledgeable
operator and where it is more possible that private information may be co=
nveyed via route
information pertaining to =
individuals' personal equipment.

There are probably several different options=
 - around what requires integrity protection, what
needs confidentiality, what should be built in as a protocol extens=
ion versus what can be used
at the transpor=
t layer.

I don't have any technical opinion or preference - but this needs to=
 be easy enough for a small
enterprise or h=
ome user to pull equipment from different vendors out of the boxes over a p=
eriod
of years - and have them work securel=
y together.=C2=A0 I don't have solutions for the keying issues -
<=
div class=3D"gmail_extra">or thoughts as to whether opportunistic encryptio=
n might be good in some cases.

Regards,
Alia


On Wed, Nov 8, 2017 at 8:44 PM, David Schinazi <dsc=
hinazi@apple.com> wrote:
Hi Alia,
I strongly believe the security should be decoupled from th=
e routing protocol.
You could have a network where parts of it ar=
e using DTLS, parts use IPsec,
parts are in a bunker on the moon =
and rely on physical security.
Babel was designed to be used in h=
eterogeneous networks.
While I suspect Juliusz originally meant W=
i-Fi vs Ethernet, I think this key
principle of the protocol appl=
ies to local security properties as well.

Thanks,<=
/div>
David


On Nov 8, 2017, at 11:25, Alia Atlas <akatlas@gmail.com> wrote:
<=
div>
Hi James,
=

On Wed, Nov 8, 2017 at 2:10 PM, james woodya=
tt=C2=A0<jhw=
@google.com>=C2=A0wrote:
On Nov 8, 2=
017, at 10:47, Alia Atlas <akatlas@gmail.com> wrote:
=

On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon=C2=A0<mellon@fugue.com>=C2=A0wrote:
On Nov 8, =
2017, at 8:40 PM, Alia Atlas <akatlas@gmail.com> wrote:
I strongly agree.=C2=A0 At least a mandatory-to-implement hop-to-hop =
security mechanism and what attacks it protects against is critical.
<=
/div>

A security model that protects agai=
nst _anything_ requires it to actually be secure. =C2=A0 The current draft =
has no such mechanism. =C2=A0 So if you want to make something MTI, we can&=
#39;t do it with the current draft, or we'd be requiring people to impl=
ement mickey-mouse security.

Re=
quiring a transport security isn't feasible?

A=
 new routing protocol without solid security is not going to progress succe=
ssfully.=C2=A0

I think the compromise I was proposing is that RFC6126bis could be=
 published with a =E2=80=9Cstrong admonition=E2=80=9D in its Security Consi=
derations section that various security vulnerabilities are available unles=
s an appropriate hop-by-hop security layer according to the deployment mode=
l is also used in conjunction with RFC 6126bis. I suspect the Working Group=
 would prefer this instead of actually specifying and requiring a mandatory=
-to-implement security layer suitable for all deployment models. You=E2=80=
=99re saying the Working Group is going to lose that argument.
Having a procedural requirement to establish a tight coupling =
between the routing protocol and its universal and integrated security laye=
r for Babel to progress successfully is a good thing to have aired before t=
he end of Working Group Last Call.

<=
div>=C2=A0Let me add in Kathleen and Eric here as well.

I have to take a read through the updated draft myself, but I can see=
 no reason to not adequately address control-plane security in
a =
new routing protocol when it is moving to the Standards track.=C2=A0 Making=
 sure that security is adequately addressed is one of the
attribu=
tes that we look for in standards track work.

The =
charter does say "Particular emphasis will =
be placed on work needed=C2=A0for a Proposed Standard routing protocol, such=
 as ensuring manageability=C2=A0
and strong security."=C2=A0 and =
among the Work Items are:

"=C2=A0Address security needs for BABEL. This may include using =
the
techniques in RFC 7298, or other=
 alternatives. Security may be
included in the base spec or the base s=
pec may normatively reference a
separate Proposed Standard specificati=
on. This is required as part of
moving Babel to Proposed Standard.&quo=
t;

=

I am very pleased with the work and dis=
cussion so far on clarifying and improving Babel.
<=
span style=3D"font-size:15px">This aspect is also critical.

Regards,
Alia

_______________________________________________babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/l=
istinfo/babel




--001a114732dcd472f4055d83ddd7--


From nobody Wed Nov  8 19:00:42 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76546129467 for ; Wed,  8 Nov 2017 19:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=apple.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 DHweZ0P9RHWl for ; Wed,  8 Nov 2017 19:00:35 -0800 (PST)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A1E120713 for ; Wed,  8 Nov 2017 19:00:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510196435; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dk/C01eTqgawgsLxOulKKPRQmWOIXlG61w3SSxWVj5k=; b=YwbVgR/Tj3AjX8Ymm8WUnUUvawH0LT5zhvELoVqicScpqK9nFRhtZ6hooSPq3OTj k70Uk68qlP/NHFhHsl3gXCjufq5URE7BzkLbzA9ykLEzp5vi95yOU5L90mkTkdS/ WTaxy3q/yrgQ8GDvDWmlHMfgtZGrT24IDhnHIdPDJmVymbAtyigNudMOEHESMu3i FRvdNfm7ybjOH0UsVdszi9RpW5Odu/Q03BeP4nJcsFTC26CbyNq+aJmmV+puug9f y8YNRymnYTt97yfwZqSqGPT2QftrvPPksYUAN8lSSdkuEst7bZoF/RgqEeOULHQ5 Y7e/92kcTFRG+MaofEe9Qw==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 62.CB.22347.3D4C30A5; Wed,  8 Nov 2017 19:00:35 -0800 (PST)
X-AuditID: 11973e11-163b19c00000574b-af-5a03c4d3eef0
Received: from kencur.apple.com (kencur.apple.com [17.151.62.38]) by relay6.apple.com (Apple SCV relay) with SMTP id 8D.AC.12883.3D4C30A5; Wed,  8 Nov 2017 19:00:35 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_IZGqBLCPZ00xPIcTAgir7A)"
Received: from [17.234.10.143] (unknown [17.234.10.143]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZ4007E5R0UJE40@kencur.apple.com>; Wed, 08 Nov 2017 19:00:35 -0800 (PST)
Sender: dschinazi@apple.com
From: David Schinazi 
Message-id: <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com>
Date: Wed, 08 Nov 2017 19:00:29 -0800
In-reply-to: 
Cc: james woodyatt , Eric Rescorla , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF , Juliusz Chroboczek , Ted Lemon , Kathleen Moriarty , Denis Ovsienko 
To: Alia Atlas 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>     
X-Mailer: Apple Mail (2.3445.1.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUi2FAYpXv5CHOUwddjKhafHl5ittiyqJvF Ys6t7ywWK16fY7eY37qMzeJn2yFmi4ad+RZv1hxhstj6fgW7A6dH04Vl7B47Z91l91iwqdRj yZKfTB6Lt7xl9FhxciObx+THbcweWw5dZAvgiOKySUnNySxLLdK3S+DKOHWmhbHg93bGiu3/ 3jE1MC5dyNjFyMEhIWAi8eZychcjF4eQwGomiQ33jrB1MXKCxXfd/MUKkdjEKPF0+VUmkASv gKDEj8n3WEBsZoEwidsvDrNBFDUzSVxbcJkdJCEsIC3RdeEuK8gGNgEtiQNrjCB6bSTu3v8E VRIpMXtCG9gyFgFViW2nJrCC2JwCwRKTb85nBJnJLHCESWLLpD3sIHNEBJQkpr4Uhti1kEPi 2q5vzBCXKkocmTmHGSQhIXCOXWJ7bzPTBEahWUiOnYXk2FlAs5gF1CWmTMmFCGtLPHl3gRXC VpNY+HsRE7L4Aka2VYxCuYmZObqZeUZ6iQUFOal6yfm5mxhB0TjdTnAH4/FVVocYBTgYlXh4 HdYyRwmxJpYVV+YeYpTmYFES5015xRAlJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdEn9Uxg wgyZY0HcHYGWIoWSjxYKrXz/e13yqS8L392z0fp5hm3yimqei8KN6ze52O0KEXB9b31ytpZp sLLJ5l9/9q2/UFD/eePT9QZHe4tPBk9e+1yMZ9K8zoTI7bpVStJ1amc/vHxn8uP9/ANqree2 eJxkLo1/v+rq7sr7C8MDrZ54v7/6Pf6IEktxRqKhFnNRcSIAi0FSNqcCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUiON1OTffyEeYogw8L5C0+PbzEbLFlUTeL xZxb31ksVrw+x24xv3UZm8XPtkPMFg078y3erDnCZLH1/Qp2B06PpgvL2D12zrrL7rFgU6nH kiU/mTwWb3nL6LHi5EY2j8mP25g9thy6yBbAEWVok5ZfVJ5YlKJQlFxQYqtUnJGYkl8eb2ls ZOqQWFCQk6qXnJ+rpG9nk5Kak1mWWqRvl2CYcepMC2PB7+2MFdv/vWNqYFy6kLGLkZNDQsBE YtfNX6xdjFwcQgKbGCWeLr/KBJLgFRCU+DH5HguIzSwQJnH7xWE2iKJmJolrCy6zgySEBaQl ui7cBerm4GAT0JI4sMYIotdG4u79T1AlkRKzJ7SxgdgsAqoS205NYAWxOQWCJSbfnM8IMpNZ 4AiTxJZJe9hB5ogIKElMfSkMsWshh8S1Xd+YIS5VlDgycw7zBEb+WUjum4XkvllA7cwC6hJT puRChLUlnry7wAphq0ks/L2ICVl8ASPbKkaBotScxEozPXi4bWIERWNDYdQOxoblVocYBTgY lXh4HdYyRwmxJpYVV+YeYpTgYFYS4b1zCCjEm5JYWZValB9fVJqTWnyI0QfoyYnMUqLJ+cBE kVcSb2hsYWxpYmFgYGJpZoJDWEmctyODIUpIID2xJDU7NbUgtQhmHBMHp1QDY9uLm9YXhR+o Hefcv/9lpPjicxZv9zXqmPxe2nz0PvckJsFf2reD6/v3qb2YnLPY+pjz5z7bKZohaqZPXy1+ d/Brisy7Rtt7q9Smeuqsn17A6bX5aeOem+0PFvjcPt71PfvV236ZM/Pl5RV0Jq3bHnTv4zu9 VZ2qa6yd7cpPNCWGpXXrfPUT61NiAaYwQy3mouJEAOdxC2rzAgAA
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 03:00:38 -0000

--Boundary_(ID_IZGqBLCPZ00xPIcTAgir7A)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

Alia,

I agree with that use case, but I think this should be standardized as =
part of the
Babel Homenet Profile. For different vendors to interoperate we will =
need that.
Today a Babel device that only has ethernet ports will not interoperate =
with
a device that only has Wi-Fi, and that's not a deficiency. Even if we =
were to
mandate a solution (e.g. Babel over DTLS), that will not improve =
security
if we do not specify how to establish trust. That's why I think security =
should be
handled per use case, and for example I really hope we will standardize =
how
to establish trust, exchange keys and secure Babel for the Homenet.
At the end of the day encryption and integrity only work when you've
established trust, and that can't be done in a way that works for all
possible use cases.

David


> On Nov 8, 2017, at 18:50, Alia Atlas  wrote:
>=20
> Hi David,
>=20
> I do agree that flexibility is important. The logic behind having one =
mandatory-to-implement
> security mechanism is that the different implementations are able to =
securely interoperate.
> If one vendor implements DTLS and another does IPsec, then those two =
vendors can't
> interoperate securely - and since connectivity is almost always viewed =
as more critical than
> security, that is the one that gets tossed.
>=20
> This is particularly important in a home environment, where one can't =
assume a knowledgeable
> operator and where it is more possible that private information may be =
conveyed via route
> information pertaining to individuals' personal equipment.
>=20
> There are probably several different options - around what requires =
integrity protection, what
> needs confidentiality, what should be built in as a protocol extension =
versus what can be used
> at the transport layer.
>=20
> I don't have any technical opinion or preference - but this needs to =
be easy enough for a small
> enterprise or home user to pull equipment from different vendors out =
of the boxes over a period
> of years - and have them work securely together.  I don't have =
solutions for the keying issues -
> or thoughts as to whether opportunistic encryption might be good in =
some cases.
>=20
> Regards,
> Alia
>=20
>=20
> On Wed, Nov 8, 2017 at 8:44 PM, David Schinazi > wrote:
> Hi Alia,
>=20
> I strongly believe the security should be decoupled from the routing =
protocol.
> You could have a network where parts of it are using DTLS, parts use =
IPsec,
> parts are in a bunker on the moon and rely on physical security.
> Babel was designed to be used in heterogeneous networks.
> While I suspect Juliusz originally meant Wi-Fi vs Ethernet, I think =
this key
> principle of the protocol applies to local security properties as =
well.
>=20
> Thanks,
> David
>=20
>=20
>> On Nov 8, 2017, at 11:25, Alia Atlas > wrote:
>>=20
>> Hi James,
>>=20
>> On Wed, Nov 8, 2017 at 2:10 PM, james woodyatt > wrote:
>> On Nov 8, 2017, at 10:47, Alia Atlas > wrote:
>>> On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon > wrote:
>>> On Nov 8, 2017, at 8:40 PM, Alia Atlas > wrote:
>>>> I strongly agree.  At least a mandatory-to-implement hop-to-hop =
security mechanism and what attacks it protects against is critical.
>>>=20
>>> A security model that protects against _anything_ requires it to =
actually be secure.   The current draft has no such mechanism.   So if =
you want to make something MTI, we can't do it with the current draft, =
or we'd be requiring people to implement mickey-mouse security.
>>>=20
>>> Requiring a transport security isn't feasible?
>>>=20
>>> A new routing protocol without solid security is not going to =
progress successfully.=20
>>=20
>> I think the compromise I was proposing is that RFC6126bis could be =
published with a =E2=80=9Cstrong admonition=E2=80=9D in its Security =
Considerations section that various security vulnerabilities are =
available unless an appropriate hop-by-hop security layer according to =
the deployment model is also used in conjunction with RFC 6126bis. I =
suspect the Working Group would prefer this instead of actually =
specifying and requiring a mandatory-to-implement security layer =
suitable for all deployment models. You=E2=80=99re saying the Working =
Group is going to lose that argument.
>>=20
>> Having a procedural requirement to establish a tight coupling between =
the routing protocol and its universal and integrated security layer for =
Babel to progress successfully is a good thing to have aired before the =
end of Working Group Last Call.
>>=20
>>  Let me add in Kathleen and Eric here as well.
>>=20
>> I have to take a read through the updated draft myself, but I can see =
no reason to not adequately address control-plane security in
>> a new routing protocol when it is moving to the Standards track.  =
Making sure that security is adequately addressed is one of the
>> attributes that we look for in standards track work.
>>=20
>> The charter does say "Particular emphasis will be placed on work =
needed=20
>> for a Proposed Standard routing protocol, such as ensuring =
manageability=20
>> and strong security."  and among the Work Items are:
>>=20
>> " Address security needs for BABEL. This may include using the
>> techniques in RFC 7298, or other alternatives. Security may be
>> included in the base spec or the base spec may normatively reference =
a
>> separate Proposed Standard specification. This is required as part of
>> moving Babel to Proposed Standard."
>>=20
>> I am very pleased with the work and discussion so far on clarifying =
and improving Babel.
>> This aspect is also critical.
>>=20
>> Regards,
>> Alia
>>=20
>> _______________________________________________
>> babel mailing list
>> babel@ietf.org 
>> https://www.ietf.org/mailman/listinfo/babel =

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


--Boundary_(ID_IZGqBLCPZ00xPIcTAgir7A)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable


Alia,

I agree with =
that use case, but I think this should be standardized as part of =
the
Babel Homenet Profile. For different vendors to =
interoperate we will need that.
Today a Babel =
device that only has ethernet ports will not interoperate with
a device that only has Wi-Fi, and that's not a deficiency. =
Even if we were to
mandate a solution (e.g. Babel =
over DTLS), that will not improve security
if we do =
not specify how to establish trust. That's why I think security should =
be
handled per use case, and for example I really =
hope we will standardize how
to establish trust, =
exchange keys and secure Babel for the Homenet.
At =
the end of the day encryption and integrity only work when =
you've
established trust, and that can't be done in =
a way that works for all
possible use =
cases.

David


On Nov =
8, 2017, at 18:50, Alia Atlas <akatlas@gmail.com> wrote:

Hi David,

I do agree that flexibility is important. The =
logic behind having one mandatory-to-implement
security mechanism is that the different =
implementations are able to securely interoperate.
If one vendor implements DTLS and another does =
IPsec, then those two vendors can't
interoperate securely - and since connectivity is =
almost always viewed as more critical than
security, that is the one that gets =
tossed.

This is particularly important in a home =
environment, where one can't assume a knowledgeable
operator and where it is more possible that =
private information may be conveyed via route
information pertaining to individuals' personal =
equipment.

There are probably several different options - =
around what requires integrity protection, what
needs confidentiality, what should be built in as =
a protocol extension versus what can be used
at the transport layer.

I =
don't have any technical opinion or preference - but this needs to be =
easy enough for a small
enterprise or =
home user to pull equipment from different vendors out of the boxes over =
a period
of years - and have them work =
securely together.  I don't have solutions for the keying issues =
-
or thoughts as to whether =
opportunistic encryption might be good in some cases.

Regards,
Alia


On Wed, Nov 8, 2017 at 8:44 PM, David Schinazi =
<dschinazi@apple.com> =
wrote:
Hi =
Alia,

I strongly =
believe the security should be decoupled from the routing =
protocol.
You could have a network where parts of =
it are using DTLS, parts use IPsec,
parts are in a =
bunker on the moon and rely on physical security.
Babel was designed to be used in heterogeneous =
networks.
While I suspect Juliusz originally meant =
Wi-Fi vs Ethernet, I think this key
principle of =
the protocol applies to local security properties as well.

Thanks,
David


On Nov 8, 2017, at 11:25, Alia Atlas <akatlas@gmail.com> wrote:

Hi James,

On Wed, Nov 8, 2017 at 2:10 PM, james =
woodyatt <jhw@google.com> wrote:
On =
Nov 8, 2017, at 10:47, Alia Atlas <akatlas@gmail.com> wrote:
On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon <mellon@fugue.com> wrote:
On Nov 8, 2017, at 8:40 PM, Alia Atlas =
<akatlas@gmail.com> wrote:
I strongly agree.  At least a mandatory-to-implement =
hop-to-hop security mechanism and what attacks it protects against is =
critical.

A security model that protects against _anything_ requires it =
to actually be secure.   The current draft has no such mechanism. =
  So if you want to make something MTI, we can't do it with the =
current draft, or we'd be requiring people to implement mickey-mouse =
security.

Requiring a transport security isn't =
feasible?

A =
new routing protocol without solid security is not going to progress =
successfully. 

I think the compromise I =
was proposing is that RFC6126bis could be published with a =E2=80=9Cstrong=
 admonition=E2=80=9D in its Security Considerations section that various =
security vulnerabilities are available unless an appropriate hop-by-hop =
security layer according to the deployment model is also used in =
conjunction with RFC 6126bis. I suspect the Working Group would prefer =
this instead of actually specifying and requiring a =
mandatory-to-implement security layer suitable for all deployment =
models. You=E2=80=99re saying the Working Group is going to lose that =
argument.

Having=
 a procedural requirement to establish a tight coupling between the =
routing protocol and its universal and integrated security layer for =
Babel to progress successfully is a good thing to have aired before the =
end of Working Group Last Call.

 Let me add in =
Kathleen and Eric here as well.

I have to take a read through the =
updated draft myself, but I can see no reason to not adequately address =
control-plane security in
a new routing protocol =
when it is moving to the Standards track.  Making sure that =
security is adequately addressed is one of the
attributes that we look for in standards track =
work.

The =
charter does say "Particular emphasis will be placed on work needed 
for a Proposed Standard =
routing protocol, such as ensuring manageability 
and strong security."  and among the Work Items =
are:

" Address security needs for =
BABEL. This may include using the
techniques in RFC 7298, or =
other alternatives. Security may be
included in the base spec or the base spec may normatively =
reference a
separate Proposed Standard specification. This is required as =
part of
moving Babel to Proposed Standard."

I am very pleased with the work and =
discussion so far on clarifying and improving =
Babel.
This aspect is also =
critical.

Regards,
Alia

_______________________________________________
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

=

--Boundary_(ID_IZGqBLCPZ00xPIcTAgir7A)--


From nobody Wed Nov  8 20:18:55 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E0C129A90 for ; Wed,  8 Nov 2017 20:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRGhNvvJiZgh for ; Wed,  8 Nov 2017 20:18:50 -0800 (PST)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 2AC341286D6 for ; Wed,  8 Nov 2017 20:18:50 -0800 (PST)
Received: by mail-wr0-x22a.google.com with SMTP id j15so4352341wre.8 for ; Wed, 08 Nov 2017 20:18:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RvfCKbFKJ77P4KttMCIOuuhLVWHYNi6qdrPJHn1nqE0=; b=ipqxI0JZP+E/aZ33YjaPRYJYy/lwx+kNw2rdu2FHDaR8RpM2x/w+p0n7qFLUgsPrX1 u5mT4XqoeDGO9Ysen7gdHiIlXS6wxgWaQoIqaWiT1z8l5Hba49EtI78Cf7UkW1nLffL3 vPQp0E2uc40f+7dpe2kYsWem37IB5zX61f+zMXT2Uc6o5/b5MrDYtNsSm31R0cpYmSoh uJ5pg3OgzIB0m50dGB5Z4UEuMJLr4d4oiArUPE4yNXQlVGdJIXxQv5t7ZD8o5bYSGekC sDRUzpZpWlRS17xH/1/mpqiqFKrHE+fdw+PYULq/IISF4VoKyKKR6qDbi2QT1kSy2gXe 1iKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RvfCKbFKJ77P4KttMCIOuuhLVWHYNi6qdrPJHn1nqE0=; b=bBoiAQz78nDTgAx1bvnQv0qCb3yc83ITA2/Aj6rN5/H7HoA9zKuz25WjaspTk4yBgT Ue5Q22YgE/mETtPyxA00wioytMgdZHXJuBHlvURF01QQxiYS37EL1LY+OFyjmLfqLwXx AyC4xeG0OPfRfP7uZ1jZs47j4qCDheUQ86jakcprkl/grPmQsSs0Ze3Ar1DOSS/sRbxQ tUNXtYH9Ro22NA7RhbgcQI6Jqj21hZWtdE6SlnZiyQMMSNG4s2XXdgFGew5SJ6azSwLp HMlNl7om/9aA5/vnOLVj1ZA5s/GGLUsjqw+DY0JxGtrrAL9p6A80zaa53xjBtVDuRhNo 70cw==
X-Gm-Message-State: AJaThX6oDjbzsHSYtaF8ZZhW+iqj+BSdXPKnSicco9EZZDqJNK2k8lTs ATLQujBWgUfZ4uvKp2yg3QeaVfSWzjLAkbkcBvvVIA==
X-Google-Smtp-Source: ABhQp+SIHdq9skcALIoUH3AgfWYeVeb4vI4aMoS/30vUK8Nt+M2QCzcfOQT27nD8Poml8ochvrDGvdbhpEKNFO0ApEs=
X-Received: by 10.223.197.17 with SMTP id q17mr2148716wrf.270.1510201128502; Wed, 08 Nov 2017 20:18:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.150.10 with HTTP; Wed, 8 Nov 2017 20:18:47 -0800 (PST)
In-Reply-To: <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com>
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>      <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com>
From: Alia Atlas 
Date: Wed, 8 Nov 2017 23:18:47 -0500
Message-ID: 
To: David Schinazi 
Cc: james woodyatt , Eric Rescorla ,  =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= ,  Babel at IETF , Juliusz Chroboczek , Ted Lemon ,  Kathleen Moriarty , Denis Ovsienko 
Content-Type: multipart/alternative; boundary="089e0826b188cdcd39055d851939"
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 04:18:53 -0000

--089e0826b188cdcd39055d851939
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

David,

The charter is unspecific as to whether it is a mechanism that is integral
to Babel,
an extension as with the pre-standard Babel, or over a transport.  There
does have
to be a dependency (normative reference) on something to implement.

There's a long history of discussion on automatic key management.  If the
basic
mechanism is in place, even opportunistic security can be better than
nothing.
Having a manual key put in isn't good - but having the support for a key
allows
better ways of building trust.

I haven't been following homenet closely. What does the Babel Homenet
Profile currently
say on this?  How far away is that from being finished.

Regards,
Alia

On Wed, Nov 8, 2017 at 10:00 PM, David Schinazi  wrote=
:

> Alia,
>
> I agree with that use case, but I think this should be standardized as
> part of the
> Babel Homenet Profile. For different vendors to interoperate we will need
> that.
> Today a Babel device that only has ethernet ports will not interoperate
> with
> a device that only has Wi-Fi, and that's not a deficiency. Even if we wer=
e
> to
> mandate a solution (e.g. Babel over DTLS), that will not improve security
> if we do not specify how to establish trust. That's why I think security
> should be
> handled per use case, and for example I really hope we will standardize h=
ow
> to establish trust, exchange keys and secure Babel for the Homenet.
> At the end of the day encryption and integrity only work when you've
> established trust, and that can't be done in a way that works for all
> possible use cases.
>
> David
>
>
> On Nov 8, 2017, at 18:50, Alia Atlas  wrote:
>
> Hi David,
>
> I do agree that flexibility is important. The logic behind having one
> mandatory-to-implement
> security mechanism is that the different implementations are able to
> securely interoperate.
> If one vendor implements DTLS and another does IPsec, then those two
> vendors can't
> interoperate securely - and since connectivity is almost always viewed as
> more critical than
> security, that is the one that gets tossed.
>
> This is particularly important in a home environment, where one can't
> assume a knowledgeable
> operator and where it is more possible that private information may be
> conveyed via route
> information pertaining to individuals' personal equipment.
>
> There are probably several different options - around what requires
> integrity protection, what
> needs confidentiality, what should be built in as a protocol extension
> versus what can be used
> at the transport layer.
>
> I don't have any technical opinion or preference - but this needs to be
> easy enough for a small
> enterprise or home user to pull equipment from different vendors out of
> the boxes over a period
> of years - and have them work securely together.  I don't have solutions
> for the keying issues -
> or thoughts as to whether opportunistic encryption might be good in some
> cases.
>
> Regards,
> Alia
>
>
> On Wed, Nov 8, 2017 at 8:44 PM, David Schinazi 
> wrote:
>
>> Hi Alia,
>>
>> I strongly believe the security should be decoupled from the routing
>> protocol.
>> You could have a network where parts of it are using DTLS, parts use
>> IPsec,
>> parts are in a bunker on the moon and rely on physical security.
>> Babel was designed to be used in heterogeneous networks.
>> While I suspect Juliusz originally meant Wi-Fi vs Ethernet, I think this
>> key
>> principle of the protocol applies to local security properties as well.
>>
>> Thanks,
>> David
>>
>>
>> On Nov 8, 2017, at 11:25, Alia Atlas  wrote:
>>
>> Hi James,
>>
>> On Wed, Nov 8, 2017 at 2:10 PM, james woodyatt  wrote:
>>
>>> On Nov 8, 2017, at 10:47, Alia Atlas  wrote:
>>>
>>> On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon  wrote:
>>>
>>>> On Nov 8, 2017, at 8:40 PM, Alia Atlas  wrote:
>>>>
>>>> I strongly agree.  At least a mandatory-to-implement hop-to-hop
>>>> security mechanism and what attacks it protects against is critical.
>>>>
>>>>
>>>> A security model that protects against _anything_ requires it to
>>>> actually be secure.   The current draft has no such mechanism.   So if=
 you
>>>> want to make something MTI, we can't do it with the current draft, or =
we'd
>>>> be requiring people to implement mickey-mouse security.
>>>>
>>>
>>> Requiring a transport security isn't feasible?
>>>
>>> A new routing protocol without solid security is not going to progress
>>> successfully.
>>>
>>>
>>> I think the compromise I was proposing is that RFC6126bis could be
>>> published with a =E2=80=9Cstrong admonition=E2=80=9D in its Security Co=
nsiderations section
>>> that various security vulnerabilities are available unless an appropria=
te
>>> hop-by-hop security layer according to the deployment model is also use=
d in
>>> conjunction with RFC 6126bis. I suspect the Working Group would prefer =
this
>>> instead of actually specifying and requiring a mandatory-to-implement
>>> security layer suitable for all deployment models. You=E2=80=99re sayin=
g the
>>> Working Group is going to lose that argument.
>>>
>>> Having a procedural requirement to establish a tight coupling between
>>> the routing protocol and its universal and integrated security layer fo=
r
>>> Babel to progress successfully is a good thing to have aired before the=
 end
>>> of Working Group Last Call.
>>>
>>
>>  Let me add in Kathleen and Eric here as well.
>>
>> I have to take a read through the updated draft myself, but I can see no
>> reason to not adequately address control-plane security in
>> a new routing protocol when it is moving to the Standards track.  Making
>> sure that security is adequately addressed is one of the
>> attributes that we look for in standards track work.
>>
>> The charter does say "Particular emphasis will be placed on work needed
>> for a Proposed Standard routing protocol, such as ensuring manageability
>> and strong security."  and among the Work Items are:
>>
>> " Address security needs for BABEL. This may include using the
>> techniques in RFC 7298, or other alternatives. Security may be
>> included in the base spec or the base spec may normatively reference a
>> separate Proposed Standard specification. This is required as part of
>> moving Babel to Proposed Standard."
>>
>> I am very pleased with the work and discussion so far on clarifying and
>> improving Babel.
>> This aspect is also critical.
>>
>> Regards,
>> Alia
>>
>> _______________________________________________
>> 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
>
>
>

--089e0826b188cdcd39055d851939
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


David,

The charter is unspecific as to =
whether it is a mechanism that is integral to Babel,
an extension=
 as with the pre-standard Babel, or over a transport.=C2=A0 There does have=

to be a dependency (normative reference) on something to impleme=
nt.

There's a long history of discussion on au=
tomatic key management.=C2=A0 If the basic
mechanism is in place,=
 even opportunistic security can be better than nothing.
Having a=
 manual key put in isn't good - but having the support for a key allows=

better ways of building trust.

I haven&=
#39;t been following homenet closely. What does the Babel Homenet Profile c=
urrently
say on this?=C2=A0 How far away is that from being finis=
hed.

Regards,
Alia

On Wed, Nov 8, 2017 at 10:0=
0 PM, David Schinazi <dschinazi@apple.com> wrote:
Alia,

I agree with that use case, =
but I think this should be standardized as part of the
Babel Homenet Pr=
ofile. For different vendors to interoperate we will need that.
T=
oday a Babel device that only has ethernet ports will not interoperate with=

a device that only has Wi-Fi, and that's not a deficiency. E=
ven if we were to
mandate a solution (e.g. Babel over DTLS), that=
 will not improve security
if we do not specify how to establish =
trust. That's why I think security should be
handled per use =
case, and for example I really hope we will standardize how
to es=
tablish trust, exchange keys and secure Babel for the Homenet.
At=
 the end of the day encryption and integrity only work when you've
established trust, and that can't be done in a way that works for=
 all
possible use cases.

David


On Nov 8, 2017, at=
 18:50, Alia Atlas <akatlas@gmail.com> wrote:

Hi David,

I do agree that flexibility =
is important. The logic behind having one mandatory-to-implement
security mechanism is that the different implementati=
ons are able to securely interoperate.
If o=
ne vendor implements DTLS and another does IPsec, then those two vendors ca=
n't
interoperate securely - and since c=
onnectivity is almost always viewed as more critical than
security, that is the one that gets tossed.

This is particularly=
 important in a home environment, where one can't assume a knowledgeabl=
e
operator and where it is more possible th=
at private information may be conveyed via route
information pertaining to individuals' personal equipment.
<=
div class=3D"gmail_extra">
There are pr=
obably several different options - around what requires integrity protectio=
n, what
needs confidentiality, what should =
be built in as a protocol extension versus what can be used
at the transport layer.
I don't have any technical opinion o=
r preference - but this needs to be easy enough for a small
enterprise or home user to pull equipment from different v=
endors out of the boxes over a period
of ye=
ars - and have them work securely together.=C2=A0 I don't have solution=
s for the keying issues -
or thoughts as to=
 whether opportunistic encryption might be good in some cases.

Regards,
Alia


On Wed, Nov 8, 2017 at=
 8:44 PM, David Schinazi <dschinazi@apple.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
Hi Alia,

I strongly believe the secu=
rity should be decoupled from the routing protocol.
You could hav=
e a network where parts of it are using DTLS, parts use IPsec,
pa=
rts are in a bunker on the moon and rely on physical security.
Ba=
bel was designed to be used in heterogeneous networks.
While I su=
spect Juliusz originally meant Wi-Fi vs Ethernet, I think this key
principle of the protocol applies to local security properties as well.

Thanks,
David


On N=
ov 8, 2017, at 11:25, Alia Atlas <akatlas@gmail.com> wrote:

Hi James,

On Wed, Nov 8, 2017 at 2=
:10 PM, james woodyatt=C2=A0<jhw@google.com>=C2=
=A0wrote:
On=
 Nov 8, 2017, at 10:47, Alia Atlas <akatlas@gmail.com> wrote:
On Wed, Nov 8, 2017 at 1:42 PM, Ted Lemon=C2=A0<mellon@f=
ugue.com>=C2=A0wrote:
On Nov 8, 2017, at 8:40 PM, Alia Atl=
as <akatlas@gmail=
.com> wrote:
I strongly agree.=C2=
=A0 At least a mandatory-to-implement hop-to-hop security mechanism and wha=
t attacks it protects against is critical.
A security model that protects against _anything_ requires it=
 to actually be secure. =C2=A0 The current draft has no such mechanism. =C2=
=A0 So if you want to make something MTI, we can't do it with the curre=
nt draft, or we'd be requiring people to implement mickey-mouse securit=
y.

Requiring a transport securi=
ty isn't feasible?

A new routing protocol with=
out solid security is not going to progress successfully.=C2=A0
=


I think the compr=
omise I was proposing is that RFC6126bis could be published with a =E2=80=
=9Cstrong admonition=E2=80=9D in its Security Considerations section that v=
arious security vulnerabilities are available unless an appropriate hop-by-=
hop security layer according to the deployment model is also used in conjun=
ction with RFC 6126bis. I suspect the Working Group would prefer this inste=
ad of actually specifying and requiring a mandatory-to-implement security l=
ayer suitable for all deployment models. You=E2=80=99re saying the Working =
Group is going to lose that argument.

Having a pro=
cedural requirement to establish a tight coupling between the routing proto=
col and its universal and integrated security layer for Babel to progress s=
uccessfully is a good thing to have aired before the end of Working Group L=
ast Call.

=C2=A0Let me add in K=
athleen and Eric here as well.

I have to take a re=
ad through the updated draft myself, but I can see no reason to not adequat=
ely address control-plane security in
a new routing protocol when=
 it is moving to the Standards track.=C2=A0 Making sure that security is ad=
equately addressed is one of the
attributes that we look for in s=
tandards track work.

The charter does say "Particular emphasis will be placed on work needed<=
/span>=C2=A0
for a Proposed Standard routing protocol, such as ensuring manageabilit=
y=C2=A0
and strong security."=C2=A0 and among the Work Items are:=


"=C2=A0Address=
 security needs for BABEL. This may include using the
techniques in RFC 7298, or other alternatives. Security m=
ay be
included in the base spec or the base spec may normatively refer=
ence a
separate Proposed Standard specification. This is required as p=
art of
moving Babel to Proposed Standard."

I am very pleased with the work and discussion so far on clarify=
ing and improving Babel.
This aspect is also critical.

=
Regards,
Alia

________________________=
_______________________
babe=
l mailing list
babel@ie=
tf.org
https://www.ietf.org/mailman/listinfo/babel



_______________________________________________
babel mailing list<=
br>babel@ietf.orghttps://www.ietf.org/mailman/listinfo/babel




--089e0826b188cdcd39055d851939--


From nobody Thu Nov  9 03:45:28 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405AE130019 for ; Thu,  9 Nov 2017 03:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy1SlcxY3TTX for ; Thu,  9 Nov 2017 03:45:25 -0800 (PST)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2157712FEE2 for ; Thu,  9 Nov 2017 03:45:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1510227922;  s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1073; bh=l74j1fX2YeFZ+j7jGEaa/3lOYtRhTKP6dg+Rk3/VJww=; b=BEg9ULgLqTuED/v5rGgkvbQiiK25ITPBRg5m7/5J1T0F9Tr3QXTSTcQ/udvgDfJ6 /Ttk9Vt3iA5snuc011AWrG/BSGLVDlt08b/PSYIWIhXe9VZr+FNwqUBtxamQeGnEkHm Te9ULaGDtIFAAxrzOpmcrFoPxrONqFidvEmxfAn8=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1510227922024127.34374510314524; Thu, 9 Nov 2017 03:45:22 -0800 (PST)
Date: Thu, 09 Nov 2017 11:45:22 +0000
From: Denis Ovsienko 
To: "Babel at IETF" 
Message-ID: <15fa0994c65.ebeea8bf36247.925065931701393093@ovsienko.info>
In-Reply-To: <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr>
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: 
Subject: Re: [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 11:45:26 -0000

---- On Wed, 08 Nov 2017 15:04:35 +0000 Matthieu Boutier  wrote ---- 
>Hi, 
> 
>Thank's a lot for this early review. 
> 
>> Please address the issues reported by id-nits. 
> 
>Please accept my apologizes about these nits. 
> 
>> The base Babel (bis) specification does not talk about the handling of 
>> duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed on a given 
>> destination prefix advertisement? 
> 
>I believe it is clear that a Babel node MUST NOT send two Source Prefix sub-TLVs 
>in one TLV. But If a received TLV has two Source Prefix sub-TLVs, I hesitate: 
>does a node SHOULD or MUST ignore the whole TLV? 
> 
>Does the list have an opinion? 

Hello Matthieu.

As far as protocol encoding semantics could go, more than one source prefix sub-TLV per one destination prefix TLV could mean the destination is the same in every resulting source-destination pair -- a simple form of compression. Do you think this compression gain isn't worth the complexity overhead or you just didn't consider this possibility before?

-- 

    Denis Ovsienko





From nobody Thu Nov  9 05:48:32 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDC51200F1; Thu,  9 Nov 2017 05:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwyRYDTaArvB; Thu,  9 Nov 2017 05:48:29 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF963120046; Thu,  9 Nov 2017 05:48:28 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA9DmLvU020057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Nov 2017 14:48:23 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vA9DmKiF008352; Thu, 9 Nov 2017 14:48:20 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A56C3EB21F; Thu,  9 Nov 2017 14:48:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9EcWhBS8LX1H; Thu,  9 Nov 2017 14:48:19 +0100 (CET)
Received: from host-37-32.sg.lan (unknown [172.23.37.32]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7DDA6EB364; Thu,  9 Nov 2017 14:48:18 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Matthieu Boutier 
In-Reply-To: <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com>
Date: Thu, 9 Nov 2017 14:48:18 +0100
Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Joel Halpern , rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr>
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com>
To: David Schinazi 
X-Mailer: Apple Mail (2.3445.4.7)
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, 09 Nov 2017 14:48:23 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 09 Nov 2017 14:48:21 +0100 (CET)
X-Miltered: at korolev with ID 5A045CA5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5A045CA4.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A045CA5.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5A045CA4.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/
X-j-chkmail-Score: MSGID : 5A045CA5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5A045CA4.003 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: 
Subject: Re: [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 13:48:31 -0000

> maybe I summon the wrath of the Gods of the Internet.

Hey! What's the protocol for that? :p

> If you don't expect this to ever be useful, no need to specify it.

Looks good for me, does something like the following make sense?  Should =
we
recommend something?

    A node does not expect to receive any TLV with two Source Prefix =
sub-TLVs or
    more.  Whenever that occurs, the behaviour is undefined: an =
implementation
    may drop the whole packet, the whole TLV or consider only just one =
of the
    sub-TLVs (this can be the case if the implementation does not check =
if
    multiple sub-TLVs are sent).

Toke, would you like to see: "It is recommended to ignore the whole =
packet".
(lower case "recommended")

Matthieu


From nobody Thu Nov  9 05:54:22 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE7F120046; Thu,  9 Nov 2017 05:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv-lpA_KlNcu; Thu,  9 Nov 2017 05:54:14 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A489126BFD; Thu,  9 Nov 2017 05:54:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7CA74245B71; Thu,  9 Nov 2017 05:54:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1510235654; bh=vbukJqV+FOdoPoMCeqXBzhvbwi8aQNWnJWNRJTLAd6g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TCwlAO4sFHGRP2F/wocXyPZF4gf7dr7Cn93UV1fSfgK7xzvdMi6mnoqxPfCrnUJog Ke4LH9ZnSQ6KDobYJU6UlFNUO0YnKNJmQKIMNhZbWFf4sTtgSWzC3NJWzkkeS/Zu2O R59yULyXqm9qiX+RJQmgva6hsjB56ETRhCmW/b2w=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E0C56240E4E; Thu,  9 Nov 2017 05:54:12 -0800 (PST)
To: Matthieu Boutier , David Schinazi 
Cc: rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , babel@ietf.org, Joel Halpern 
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com> <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr>
From: "Joel M. Halpern" 
Message-ID: 
Date: Thu, 9 Nov 2017 08:54:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 13:54:16 -0000

Being a little bit picky here:

Could you also add a sentence in section 7.1 stating explicitly that 
only one source specific prefix is permitted in a TLV?  I realize this 
is implied by the use of "a source prefix" in section 5.1.  I think it 
would help to be explicit.

If the sending side restriction is made explicit, then the text you 
propose for the receiving side is acceptable, although I would 
personally prefer that it used an upper case SHOULD for ignoring the 
whole TLV.  This preference is driven by a desire for robustness and 
predictability in interoperation.

Yours,
Joel

On 11/9/17 8:48 AM, Matthieu Boutier wrote:
>> maybe I summon the wrath of the Gods of the Internet.
> 
> Hey! What's the protocol for that? :p
> 
>> If you don't expect this to ever be useful, no need to specify it.
> 
> Looks good for me, does something like the following make sense?  Should we
> recommend something?
> 
>      A node does not expect to receive any TLV with two Source Prefix sub-TLVs or
>      more.  Whenever that occurs, the behaviour is undefined: an implementation
>      may drop the whole packet, the whole TLV or consider only just one of the
>      sub-TLVs (this can be the case if the implementation does not check if
>      multiple sub-TLVs are sent).
> 
> Toke, would you like to see: "It is recommended to ignore the whole packet".
> (lower case "recommended")
> 
> Matthieu
> 
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
> 


From nobody Thu Nov  9 09:02:29 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9301276AF for ; Thu,  9 Nov 2017 09:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG01n6JMeHP6 for ; Thu,  9 Nov 2017 09:02:27 -0800 (PST)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F232B1274A5 for ; Thu,  9 Nov 2017 09:02:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1510246941;  s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=2232; bh=4j9IO+GaT5sfL0I+QTz+XwPdwBpzWAlXkT8PJMlzjOo=; b=L02MHfyv41uTQg3R1n5QF7G7BsPYYJRdhnQu149EbLr8fZMYWfBZV7X3KIFL2KHM /AJSD5S8mRwKw2CYFmFPGnIHOSuXaFSJmwEltjcl2JB7HmnmLy6qVDeqNIb/Bzxo77W nyC9rMtnDwt/XfxUiXSQxb9LqEJU9iceAYu+cs3Y=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1510246941147777.8941421574449; Thu, 9 Nov 2017 09:02:21 -0800 (PST)
Date: Thu, 09 Nov 2017 17:02:21 +0000
From: Denis Ovsienko 
To: "Babel at IETF" 
Message-ID: <15fa1bb81d7.109d24d1b49274.2604017698454390895@ovsienko.info>
In-Reply-To: <437846EA-91C2-419B-AC9F-04D88C9C43D7@irif.fr>
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <15fa0994c65.ebeea8bf36247.925065931701393093@ovsienko.info> <437846EA-91C2-419B-AC9F-04D88C9C43D7@irif.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: 
Subject: Re: [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 17:02:28 -0000

---- On Thu, 09 Nov 2017 13:45:32 +0000 Matthieu Boutier  wrote ---- 
>Hello Denis, 
> 
>> more than one source prefix sub-TLV per one destination prefix TLV could mean the destination is the same in every resulting source-destination pair -- a simple form of compression. 
> 
>I see three reasons to avoid this (random order): 
> 
> - I believe that Babel takes care to not overload its protocol: there should 
> not be two way to express the same thing. 
> 
> - Having such working compression would be extremely rare since it would be 
> impossible if the two routes (having the same destination) have the same 
> metric and other properties. 
> 
> - The compression mechanism already compress the destination prefix in a 
> very more flexible way. 

Thanks for the response.

So, the (Interval, Seqno, Metric) triplet makes such compression useless and simplicity is a valid argument. I accept those points.

With this in mind I was going to suggest that when the protocol instance expects 0 or 1 Source Prefix sub-TLVs in a TLV but encounters more than 1, that makes the TLV malformed, therefore the TLV must be ignored. But do you think the following text in 6126-bis Section 4.6.9 deserves additional attention?

   An Update TLV advertises or retracts a route.  As an optimisation, it
   can optionally have the side effect of establishing a new implied
   router-id and a new default prefix.

In this sense, if the instance skips a malformed Update TLV that was intended to establish the implied values, would it be right to skip subsequent TLVs because those depend on the implied values? Does this stand for both the basic protocol and the source-specific extension?

There is a straightforward statement about unknown TLV types in the base protocol specification:

   TLVs with an unknown type value MUST be silently ignored.

Perhaps it would be useful to have a fail-safe statement about known (but malformed) TLV types handling in general (not just Update).

And a closely related point: given a series of properly formed Update TLVs, if one TLV wants to establish the implied values but the protocol instance considers the update unfeasible, does it still modify the implied values?

-- 
    Denis Ovsienko




From nobody Thu Nov  9 14:31:34 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FCC127137 for ; Thu,  9 Nov 2017 14:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXM-UNHx0QtN for ; Thu,  9 Nov 2017 14:31:30 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2270D127077 for ; Thu,  9 Nov 2017 14:31:07 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA9MUw73025281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Nov 2017 23:30:59 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vA9MUrki017845; Thu, 9 Nov 2017 23:30:53 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A5641EB259; Thu,  9 Nov 2017 23:30:53 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id z7wSbAN1tU2t; Thu,  9 Nov 2017 23:30:52 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4A6AFEB21F; Thu,  9 Nov 2017 23:30:49 +0100 (CET)
Date: Thu, 09 Nov 2017 23:30:48 +0100
Message-ID: <877euzqe3r.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: David Schinazi 
Cc: Alia Atlas , james woodyatt , Eric Rescorla , Babel at IETF , Ted Lemon , Kathleen Moriarty 
In-Reply-To: <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com>
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>      <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 09 Nov 2017 23:31:01 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 09 Nov 2017 23:30:59 +0100 (CET)
X-Miltered: at korolev with ID 5A04D722.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5A04D71D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A04D722.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5A04D71D.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 : 5A04D722.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5A04D71D.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: 
Subject: [babel] About Babel security [was: WG Last Call...]
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 22:31:32 -0000

> That's why I think security should be handled per use case,

I agree with you, David, but I think Alia may have a point.  The Babel
community has to define one default security mechanism, and send a clear
message telling implementers that unless you have good reasons to do
otherwise, this is the mechanism you should be implementing.

We can discuss whether this mechanism should be MTI or strongly recommended,
but since we haven't done our homework (defining the recommended mechanism),
that discussion would be very premature at this point.

Current candidates for the recommended security mechanism include:

  - 7298bis or something similar (vide RFC 5709);
  - DTLS;
  - dynamically keyed IPsec.

There are other possibilities (e.g. statically keyed IPsec together with
an application layer replay protection mechanism), but I don't think they
are strong contenders.

Just like you, David, I love arguing about MTI (and just like you, I think
that MTI is a silly idea), but right now I suggest we be good, and
implement one or more of the above so we can have an adult discussion on
which security mechanism we wish to recommend.  (Call me an integrist, but
I really don't think one can have an adult discussion until one has tried
one's hand at implementing the protocol one supports.  You know who you
are.)  My aim would be to have an implementation of DTLS ready in time for
IETF 101, but I'm not sure I'll succeed.

If our respected chairs agree, I can make a quick presentation at IETF 100
on the subject.

-- Juliusz


From nobody Thu Nov  9 14:40:48 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605F71279EB for ; Thu,  9 Nov 2017 14:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X7_Nn0hsX0T for ; Thu,  9 Nov 2017 14:40:46 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEDF127863 for ; Thu,  9 Nov 2017 14:40:45 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA9MeihC027409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Nov 2017 23:40:44 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vA9Mei9S019813; Thu, 9 Nov 2017 23:40:44 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2AC0AEB217; Thu,  9 Nov 2017 23:40:44 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id UkpdEhMowhWU; Thu,  9 Nov 2017 23:40:43 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1907DEB216; Thu,  9 Nov 2017 23:40:43 +0100 (CET)
Date: Thu, 09 Nov 2017 23:40:42 +0100
Message-ID: <8760ajqdn9.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: Denis Ovsienko 
Cc: "Babel at IETF" 
In-Reply-To: <15fa1bb81d7.109d24d1b49274.2604017698454390895@ovsienko.info>
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <15fa0994c65.ebeea8bf36247.925065931701393093@ovsienko.info> <437846EA-91C2-419B-AC9F-04D88C9C43D7@irif.fr> <15fa1bb81d7.109d24d1b49274.2604017698454390895@ovsienko.info>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 09 Nov 2017 23:40:44 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 09 Nov 2017 23:40:44 +0100 (CET)
X-Miltered: at korolev with ID 5A04D96C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5A04D96C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A04D96C.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5A04D96C.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 : 5A04D96C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5A04D96C.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: 
Subject: Re: [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 22:40:47 -0000

> As far as protocol encoding semantics could go, more than one source
> prefix sub-TLV per one destination prefix TLV could mean the destination
> is the same in every resulting source-destination pair -- a simple form
> of compression.

Smart idea, but for the sake of simplicity I'd prefer we go with Joel's
suggestion.  (SHOULD silently drop.)

>    An Update TLV advertises or retracts a route.  As an optimisation, it
>    can optionally have the side effect of establishing a new implied
>    router-id and a new default prefix.

> In this sense, if the instance skips a malformed Update TLV that was
> intended to establish the implied values, would it be right to skip
> subsequent TLVs because those depend on the implied values? Does this
> stand for both the basic protocol and the source-specific extension?

Please see 6126bis Section 4.5.  I think that an Update with multiple
source-specific sub-TLVs should behave just like an Update with an unknown
mandatory sub-TLV: it should establish the parser state, and only then be
dropped.  In other words, checking for duplicate sub-TLVs should happen
after parsing, not during parsing.

> Perhaps it would be useful to have a fail-safe statement about known
> (but malformed) TLV types handling in general (not just Update).

Yes, that makes sense.  I'm waiting for Susan's review before I make any
updates to the text.

> And a closely related point: given a series of properly formed Update
> TLVs, if one TLV wants to establish the implied values but the protocol
> instance considers the update unfeasible, does it still modify the
> implied values?

Yes.  Unfeasible updates are parsed and processed normally, they are
avoided much later (Sections 3.5 and 3.6.)

-- Juliusz


From nobody Thu Nov  9 15:38:58 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98E81252BA for ; Thu,  9 Nov 2017 15:38:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level: 
X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIFbcVEg86us for ; Thu,  9 Nov 2017 15:38:55 -0800 (PST)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A9E124D37 for ; Thu,  9 Nov 2017 15:38:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1510270730;  s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=4051; bh=T7zfLuCj96+oUz9ktxHlrScGakF3ulAvoFgKFT6vzOQ=; b=PKiJdcxlB0HsmvZ+iVh3/IiUnI72GLibQaBk3VLh/QduKQnyAmayNAchvcFZq6mZ 2qixEXZkhDdjOywvOj/MBO0zxxgOpu0UtWTfSZ8wKyH/84KaUD7cnoQ7pH9DtlzN+o6 ViZvvOwSGujda9EgFeoomJMUZA+swSoVncLOsQpI=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1510270730342877.1412921254039; Thu, 9 Nov 2017 15:38:50 -0800 (PST)
Date: Thu, 09 Nov 2017 23:38:50 +0000
From: Denis Ovsienko 
To: "Babel at IETF" 
Message-ID: <15fa3268060.ca55f5a960479.7970407615926205397@ovsienko.info>
In-Reply-To: <87y3nhr1gm.fsf@toke.dk>
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 09 Nov 2017 23:38:57 -0000

---- On Wed, 08 Nov 2017 01:41:45 +0000 Toke H=C3=B8iland-J=C3=B8rgensen  w=
rote ----=20
>Denis Ovsienko  writes:=20
>=20
>>>Which "network protocols language" are you referring to?=20
>>>=20
>>>As I said, I did not get the same specific meaning out of Section 3.4=20
>>>when I first read it; and I have not been able to find a definition of=
=20
>>>this term anywhere through my (admittedly limited) googling. So if you=
=20
>>>could provide a reference, that would be helpful :)=20
>>=20
>> The "network protocols language" I was referring to does not have a=20
>> definite normative reference as far as I know. It is a vague set of=20
>> related concepts, but it gets more clear with studying specifications=20
>> and implementations.=20
>=20
>Right, but that makes it one of those things that reasonable people can=20
>disagree on. Which I guess what is going on here.=20
>=20
>Now, seeing as the problem this creates is a security issue, I agree=20
>with David that the security considerations section is the place to add=20
>a note. So an way to fix this would be adding something like this to the=
=20
>first paragraph of section 6 (some wordsmithing probably needed):=20
>=20
>"In particular, the bidirectional reachability detection in Babel is not=
=20
>a full handshake and does not offer any security guarantees (such as=20
>replay protection). Any security extensions to Babel need to take this=20
>into account."=20
>=20
>Would this address your concerns, do you think? :)=20

Hello all.

I tried to come up with a more detailed problem statement, after some think=
ing let me propose the following change to the current I-D:


--- a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml
+++ b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml
@@ -819,7 +819,7 @@ runs the route selection procedure ().
=20
 
=20
-

+

=20
 In order to establish bidirectional reachability, every node sends
 periodic IHU ("I Heard You") TLVs to each of its neighbours.  Since IHUs
@@ -2267,6 +2267,23 @@ from a link-local IPv6 address; since routers don't =
forward link-local IPv6
 packets, this provides protection against spoofed Babel packets being sent
 from the global Internet.  No such natural protection exists when Babel
 packets are carried over IPv4.
+
+It may be not obvious that this revision of this document specifies
+() "bidirectional reachability" in su=
ch a
+way that it is impossible to relate the data in a legitimate incoming IHU =
TLV
+to a particular prior outgoing Hello TLV. A Babel speaker will accept as a
+proof of the bidirectional reachability any IHU TLV that lists its router-=
id,
+even if the IHU TLV comes in a replayed or duplicate packet.
+
+One consequence of this is that even when the authentication mechanism
+defined in  is deployed in a network segment, a =
replay
+attack is possible if the attacker can intercept authenticated Babel packe=
ts
+on their way between two speakers and store them offline instead of the no=
rmal
+delivery. Then if the attacker later replays the stored packets towards th=
e
+receiver, the authentication mechanism will accept them because it has not
+seen them before, and the base protocol instance will process the TLVs in
+those packets, "detect" the sending neighbour and try to act respective ro=
ute
+updates.
 

=20
 

@@ -2398,6 +2415,8 @@ Hoiland-Jorgensen.  The address compression technique=
 was inspired by
   
 
=20
+
+
 
=20
 



--=20

    Denis Ovsienko





From nobody Thu Nov  9 16:21:32 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160A81242F5 for ; Thu,  9 Nov 2017 16:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_UtO-dsuNTr for ; Thu,  9 Nov 2017 16:21:30 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2A3127444 for ; Thu,  9 Nov 2017 16:21:22 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAA0LKaI013975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Nov 2017 01:21:20 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vAA0LK47003377; Fri, 10 Nov 2017 01:21:20 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 81FC1EB21F; Fri, 10 Nov 2017 01:21:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id fq4liyTtEWTc; Fri, 10 Nov 2017 01:21:19 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A2FEFEB216; Fri, 10 Nov 2017 01:21:19 +0100 (CET)
Date: Fri, 10 Nov 2017 01:21:19 +0100
Message-ID: <87375nq8zk.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: Denis Ovsienko 
Cc: "Babel at IETF" 
In-Reply-To: <15fa3268060.ca55f5a960479.7970407615926205397@ovsienko.info>
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <15fa3268060.ca55f5a960479.7970407615926205397@ovsienko.info>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 10 Nov 2017 01:21:20 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 10 Nov 2017 01:21:20 +0100 (CET)
X-Miltered: at korolev with ID 5A04F100.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5A04F100.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A04F100.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5A04F100.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 : 5A04F100.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5A04F100.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] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Nov 2017 00:21:31 -0000

> I tried to come up with a more detailed problem statement, after some
> thinking let me propose the following change to the current I-D:

Please check my message of 8 November 2017 about why I'm not going to
apply that.

-- Juliusz



From nobody Fri Nov 10 08:24:26 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD74E126DFB for ; Fri, 10 Nov 2017 08:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvrdHzNgjlNf for ; Fri, 10 Nov 2017 08:24:23 -0800 (PST)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190AD127871 for ; Fri, 10 Nov 2017 08:23:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1510331036;  s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=735; bh=0KA4Tf9LSqA23leh/CT8MTjBo+tUVkxg39V+unuqUJk=; b=CQk2bwPpZiuXJg9ZFZEtSh6g2VyTfDvkGsg5xFyJuDTFtiRyToewyMLO2FuUNOVp ggB7kZPvQgIaU/Qes4v4O/w7uBqUuectdkVOlL+J3WLZ8Xeu6TYoACIa1OkuDuANul4 FY3eHuRcsOOypHXplrhVuJw4cmDMpsEAu8nm8Zfg=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1510331036017448.5966810087815; Fri, 10 Nov 2017 08:23:56 -0800 (PST)
Date: Fri, 10 Nov 2017 16:23:56 +0000
From: Denis Ovsienko 
To: "Babel at IETF" 
Message-ID: <15fa6beb16e.b9b0e1d85229.6757012419871465181@ovsienko.info>
In-Reply-To: <87375nq8zk.wl-jch@irif.fr>
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <15fa3268060.ca55f5a960479.7970407615926205397@ovsienko.info> <87375nq8zk.wl-jch@irif.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: 
Subject: Re: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 10 Nov 2017 16:24:25 -0000

---- On Fri, 10 Nov 2017 00:21:19 +0000 Juliusz Chroboczek  wrote ---- 
>> I tried to come up with a more detailed problem statement, after some 
>> thinking let me propose the following change to the current I-D: 
> 
>Please check my message of 8 November 2017 about why I'm not going to 
>apply that. 

Hello Juliusz.

That message states that Babel is unsecure and discusses offloading the problem elsewhere, also that the proposed (at that time) additional text for the Security Considerations section does not make everything clear enough.

Now that I have clarified that additional text a little but you are still unhappy about it, would you like to suggest any improvements to the text?

Thanks.

-- 

    Denis Ovsienko





From nobody Fri Nov 10 23:10:49 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A28712706D for ; Fri, 10 Nov 2017 23:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oyw8rTGnYqZl for ; Fri, 10 Nov 2017 23:10:40 -0800 (PST)
Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 5F947128891 for ; Fri, 10 Nov 2017 23:10:40 -0800 (PST)
Received: by mail-ot0-x22e.google.com with SMTP id 105so855259oth.10 for ; Fri, 10 Nov 2017 23:10:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tQDLskutnEHMKi3qkxGfLr+Se9XM3cpvJSyd5hQfPsw=; b=UPuX2dv9uN6jsZpcaw3jnSuvqbpzi4hXppoxR2Gf4QF3VySP08O1BUS2kIR2YsleVi +lQHXKJxjW4E8qhBS/fkGWlD8XLNJpCZ4eKCNBDSnpDqNl9xeUOimNpgjxlIV9mW9P7Q KbTCaJCt6W9CmLSfSahq1Is/XhF3mVLZGwjwZvCJBowLAd4mMbqWq7mblsc1PbvA6u1V xQvEARmGoo0/dET36zXzM8aIMozX0br+bsaNRA27hMMY4RefeRjrRUkhpcTUqzrdGhEE 4aUHzVy/BshOei9xK7vNSPHyhvbfO4qs3Eo+4Qf+cmGGdb66GPsglkMWaVMNauxtHmh8 xElA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tQDLskutnEHMKi3qkxGfLr+Se9XM3cpvJSyd5hQfPsw=; b=fe9RdXra+FQPYmjDHkdxaOR/YoKLiLVVhHMoPiUlPNysqvCGnsgJj7TUqIfp0650bo NkxZC8DWJ8+NOZ8mi2s2HRlqSuyAgA1tn3Nt1jAFDrn1fQxMgrGGz34ZgRvOiXl+GvYH x+w4hBiUTc0aZJZ8W7L5A5MZwzNJljVq1TAPx3v80L/cPyKUfpHcnBiI3zCV02zbdlHR 1SBz2pvuxk0H1WSOV8ZotV8MgU079Bb0i0TwPnl1uoUQTzN2DXeSohZ3Cq00jB6M82mV uHzM4tM6ojwKiwnd7P7nlJLFku2qps6LSc+wEs6ppP27k1n+OvwaAHhYhMXXgKUFrj3k Dshg==
X-Gm-Message-State: AJaThX4Z/k9OW+zbkkYJbbq0iTl5mMX2uYWCSaJjxyeXPyvshGZnJB0h SnAgMalmQRbT3Qb/foXP5zOxx0R0upSWTe8WN5Y=
X-Google-Smtp-Source: AGs4zMYOBXMOUguWFMxA940f8dejNYa7pyEyh0NBonzUd76VfY3xGMcFQne2nCEN7WYyeTaNwPeY7wwDmHFk8qIJIHk=
X-Received: by 10.157.38.248 with SMTP id i53mr1839733otd.94.1510384239737; Fri, 10 Nov 2017 23:10:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.73.194 with HTTP; Fri, 10 Nov 2017 23:10:24 -0800 (PST)
In-Reply-To: <877euzqe3r.wl-jch@irif.fr>
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>      <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com> <877euzqe3r.wl-jch@irif.fr>
From: Donald Eastlake 
Date: Sat, 11 Nov 2017 02:10:24 -0500
Message-ID: 
To: Juliusz Chroboczek 
Cc: David Schinazi , james woodyatt , Eric Rescorla ,  Babel at IETF , Ted Lemon , Alia Atlas ,  Kathleen Moriarty 
Content-Type: multipart/alternative; boundary="001a113e20b61582fb055dafbca9"
Archived-At: 
Subject: Re: [babel] About Babel security [was: WG Last Call...]
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Nov 2017 07:10:42 -0000

--001a113e20b61582fb055dafbca9
Content-Type: text/plain; charset="UTF-8"

Hi Juliusz,

I think a presentation on security alternatives at the BABEL WG meeting
this coming Friday would be a good idea. The BABEL Charter is pretty clear
in mandating better security than that in rfc6126bis, either in rfc6126bis
or in a document normatively referenced by rfc6162bis, is a gating factor
in the approval of BABEL as an IETF Standards Track protocol.

I have submitted a Meetecho request for this, which is actually one day
past the deadline, but I'm hopefully they will accept it since it is for
the last time slot of the week...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Thu, Nov 9, 2017 at 5:30 PM, Juliusz Chroboczek  wrote:

> > That's why I think security should be handled per use case,
>
> I agree with you, David, but I think Alia may have a point.  The Babel
> community has to define one default security mechanism, and send a clear
> message telling implementers that unless you have good reasons to do
> otherwise, this is the mechanism you should be implementing.
>
> We can discuss whether this mechanism should be MTI or strongly
> recommended,
> but since we haven't done our homework (defining the recommended
> mechanism),
> that discussion would be very premature at this point.
>
> Current candidates for the recommended security mechanism include:
>
>   - 7298bis or something similar (vide RFC 5709);
>   - DTLS;
>   - dynamically keyed IPsec.
>
> There are other possibilities (e.g. statically keyed IPsec together with
> an application layer replay protection mechanism), but I don't think they
> are strong contenders.
>
> Just like you, David, I love arguing about MTI (and just like you, I think
> that MTI is a silly idea), but right now I suggest we be good, and
> implement one or more of the above so we can have an adult discussion on
> which security mechanism we wish to recommend.  (Call me an integrist, but
> I really don't think one can have an adult discussion until one has tried
> one's hand at implementing the protocol one supports.  You know who you
> are.)  My aim would be to have an implementation of DTLS ready in time for
> IETF 101, but I'm not sure I'll succeed.
>
> If our respected chairs agree, I can make a quick presentation at IETF 100
> on the subject.
>
> -- Juliusz
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>

--001a113e20b61582fb055dafbca9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Juliusz,

I think a presentation on s=
ecurity alternatives at the BABEL WG meeting this coming Friday would be a =
good idea. The BABEL Charter is pretty clear in mandating better security t=
han that in rfc6126bis, either in rfc6126bis or in a document normatively r=
eferenced by rfc6162bis, is a gating factor in the approval of BABEL as an =
IETF Standards Track protocol.

I have submitted a =
Meetecho request for this, which is actually one day past the deadline, but=
 I'm hopefully they will accept it since it is for the last time slot o=
f the week...

Thanks,
Donald<=
br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-227=
0 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com


On Thu, Nov 9, 2017 at 5:30 PM, Juliusz Chro=
boczek <jch@irif.fr> wrote:
>=
 That's why I think security should be handled per use case,



I agree with you, David, but I think Alia may have a point.=C2=A0 The Babel=


community has to define one default security mechanism, and send a clear
message telling implementers that unless you have good reasons to do

otherwise, this is the mechanism you should be implementing.



We can discuss whether this mechanism should be MTI or strongly recommended=
,

but since we haven't done our homework (defining the recommended mechan=
ism),

that discussion would be very premature at this point.



Current candidates for the recommended security mechanism include:



=C2=A0 - 7298bis or something similar (vide RFC 5709);

=C2=A0 - DTLS;

=C2=A0 - dynamically keyed IPsec.



There are other possibilities (e.g. statically keyed IPsec together with
an application layer replay protection mechanism), but I don't think th=
ey

are strong contenders.



Just like you, David, I love arguing about MTI (and just like you, I think<=
br>
that MTI is a silly idea), but right now I suggest we be good, and

implement one or more of the above so we can have an adult discussion on
which security mechanism we wish to recommend.=C2=A0 (Call me an integrist,=
 but

I really don't think one can have an adult discussion until one has tri=
ed

one's hand at implementing the protocol one supports.=C2=A0 You know wh=
o you

are.)=C2=A0 My aim would be to have an implementation of DTLS ready in time=
 for

IETF 101, but I'm not sure I'll succeed.



If our respected chairs agree, I can make a quick presentation at IETF 100<=
br>
on the subject.



-- Juliusz



_______________________________________________

babel mailing list

babel@ietf.org

https://www.ietf.org/mailman/listinfo/babel





--001a113e20b61582fb055dafbca9--


From nobody Sat Nov 11 06:20:58 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED3E129568 for ; Sat, 11 Nov 2017 06:20:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lS86-iTR7an for ; Sat, 11 Nov 2017 06:20:54 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F62C129564 for ; Sat, 11 Nov 2017 06:20:54 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vABEKqmQ027021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 11 Nov 2017 15:20:52 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vABEKqM4025186; Sat, 11 Nov 2017 15:20:52 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2DF08EB216; Sat, 11 Nov 2017 15:20:52 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ZanatgH6Viud; Sat, 11 Nov 2017 15:20:51 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 040B4EB215; Sat, 11 Nov 2017 15:20:50 +0100 (CET)
Date: Sat, 11 Nov 2017 15:20:50 +0100
Message-ID: <87r2t4gam5.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: Denis Ovsienko 
CC: babel@ietf.org
In-Reply-To: <15fa6beb16e.b9b0e1d85229.6757012419871465181@ovsienko.info>
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <15fa3268060.ca55f5a960479.7970407615926205397@ovsienko.info> <87375nq8zk.wl-jch@irif.fr> <15fa6beb16e.b9b0e1d85229.6757012419871465181@ovsienko.info>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 11 Nov 2017 15:20:52 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 11 Nov 2017 15:20:52 +0100 (CET)
X-Miltered: at korolev with ID 5A070744.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5A070744.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A070744.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5A070744.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 : 5A070744.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5A070744.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] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Nov 2017 14:20:57 -0000

>> Please check my message of 8 November 2017 about why I'm not going to 
>> apply that. 

> That message states that Babel is unsecure and discusses offloading the
> problem elsewhere,

No, it doesn't say that.  It says that singling out your pet security
property and stating that Babel doesn't have does not have it does not
improve the document.

This, Denis, is unfortunately typical of interacting with you: you keep
assuming that people are saying something, and in effect don't read what
they are actually saying.

-- Juliusz


From nobody Sat Nov 11 11:39:23 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF6A124239 for ; Sat, 11 Nov 2017 11:39:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level: 
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CVv2YkOmYeC for ; Sat, 11 Nov 2017 11:39:20 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76331204DA for ; Sat, 11 Nov 2017 11:39:19 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 22ED3207FC for ; Sat, 11 Nov 2017 14:39:19 -0500 (EST)
Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Sat, 11 Nov 2017 14:39:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RfzWKP qQKXIiiJ8DlmzyLAEsEV5Q6e1lXY5vKkKXD6A=; b=fCwei6doPypdTF11A5mm5a hKtcfJAjBVAENPHi6RraAm4GGJqr14ytPVephEXLoCc3sB3oQGNOzsWeiTt/IUF2 ndloYXnbkj/KMtk3qvUkN6C16TbvzGHTZHD6j5kXu3y8zITLsgYBixvDdgj35Mvm s4DybYpyXCpBYpgghpnad6i9iMwDCqFgvdVVmpBnoH5dnrsXLKZ293fRBhNok+KX rrPrK1wyeyW25aXv3oHHm8/jmOPcIJ6UXR2fjRXFuvkPz9f8IA3ub/VyvcAdoZou XYt/UC96Zl/ygnmFCptm2XG3qCJ/sDup32tX1QFjHwASMXg1bhOsi11SfZ8D1W6g ==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id F2A286263E; Sat, 11 Nov 2017 14:39:18 -0500 (EST)
Message-Id: <1510429158.1532491.1169298736.289E12E8@webmail.messagingengine.com>
From: Justin Kilpatrick 
To: babel@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9
Date: Sat, 11 Nov 2017 14:39:18 -0500
In-Reply-To: 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>      <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com> <877euzqe3r.wl-jch@irif.fr> 
Archived-At: 
Subject: Re: [babel] About Babel security [was: WG Last Call...]
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 11 Nov 2017 19:39:22 -0000

In addition to traffic and protocol message security I would be
interested in discussing what it would take to harden Babel against
malicious input.

Things like ratelimiting of update requests and sanity checking
prefixes. There are good questions about what's really necessary and how
it impacts the standard.

Unfortunately I won't be able to attend the WG meeting myself, a summary
or recording will have to suffice.

--
=C2=A0 Justin Kilpatrick
=C2=A0 justin@altheamesh.com



On Sat, Nov 11, 2017, at 02:10 AM, Donald Eastlake wrote:
> Hi Juliusz,
>=20
> I think a presentation on security alternatives at the BABEL WG meeting t=
his coming Friday would be a good idea. The BABEL Charter is pretty clear i=
n mandating better security than that in rfc6126bis, either in rfc6126bis o=
r in a document normatively referenced by rfc6162bis, is a gating factor in=
 the approval of BABEL as an IETF Standards Track protocol.
>=20
> I have submitted a Meetecho request for this, which is actually one day p=
ast the deadline, but I'm hopefully they will accept it since it is for the=
 last time slot of the week...
>=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
> =C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
> =C2=A0155 Beaver Street, Milford, MA 01757 USA
> =C2=A0d3e3e3@gmail.com
>=20
> On Thu, Nov 9, 2017 at 5:30 PM, Juliusz Chroboczek  wrote:
>> > That's why I think security should be handled per use case,
>>=20=20
>>  I agree with you, David, but I think Alia may have a point.=C2=A0 The B=
abel
>>  community has to define one default security mechanism, and send a clear
>>  message telling implementers that unless you have good reasons to do
>>  otherwise, this is the mechanism you should be implementing.
>>=20=20
>>  We can discuss whether this mechanism should be MTI or strongly recomme=
nded,
>>  but since we haven't done our homework (defining the recommended mechan=
ism),
>>  that discussion would be very premature at this point.
>>=20=20
>>  Current candidates for the recommended security mechanism include:
>>=20=20
>>  =C2=A0 - 7298bis or something similar (vide RFC 5709);
>>  =C2=A0 - DTLS;
>>  =C2=A0 - dynamically keyed IPsec.
>>=20=20
>>  There are other possibilities (e.g. statically keyed IPsec together with
>>  an application layer replay protection mechanism), but I don't think th=
ey
>>  are strong contenders.
>>=20=20
>>  Just like you, David, I love arguing about MTI (and just like you, I th=
ink
>>  that MTI is a silly idea), but right now I suggest we be good, and
>>  implement one or more of the above so we can have an adult discussion on
>>  which security mechanism we wish to recommend.=C2=A0 (Call me an integr=
ist, but
>>  I really don't think one can have an adult discussion until one has tri=
ed
>>  one's hand at implementing the protocol one supports.=C2=A0 You know wh=
o you
>>  are.)=C2=A0 My aim would be to have an implementation of DTLS ready in =
time for
>>  IETF 101, but I'm not sure I'll succeed.
>>=20=20
>>  If our respected chairs agree, I can make a quick presentation at IETF =
100
>>  on the subject.
>>=20=20
>>  -- Juliusz
>>=20=20
>>  _______________________________________________
>>  babel mailing list
>>  babel@ietf.org
>>  https://www.ietf.org/mailman/listinfo/babel
> _________________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel


From nobody Sat Nov 11 17:41:00 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48577128D16 for ; Sat, 11 Nov 2017 17:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNCeeR1ogRvW for ; Sat, 11 Nov 2017 17:40:57 -0800 (PST)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A3212944F for ; Sat, 11 Nov 2017 17:40:57 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id l19so7593833pgo.2 for ; Sat, 11 Nov 2017 17:40:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cXhSSZHLcdDn7dsYEXve9nHYXFDPIvMndqxV1DwT+Is=; b=RKQIZrON16Q/d084tLDWCi4pdDYhTZv1TQf/dcG2c0rpVX3d7G7DoFMz9FOYFWL2tB qQfg88BMxgFzKwnPSZrX0/fL4lnSHR0EGjy/eYxcZfIHSOnSc39VS2f7NbPNF4LO+xEk P3v93468pAZa5nfX7vBDme9vY0642EWa0ehZMgvPfvSbgwkpuSReOjT/K5FVcI9aIdhB v7CbUIDkMxfxGcknNkZnj9YfqLl8NLX7cqA8J1rDlCxalq8JlZLh0F4GqlTpT1YFiYI2 bDl3oGKZUH6/LPIuqdR6jd0Aqp4BynCCqSogJ7YXR8/Q6HJVOVByBWkKwra4OfHNsati GO6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cXhSSZHLcdDn7dsYEXve9nHYXFDPIvMndqxV1DwT+Is=; b=R/d1HHepe9/SDTUyTGZHgHilHzv8uYm8tY89Tu1AiGDMTlxVrJ9kCySqP0AjMO/v12 svzfzH9Wwpi+07Y1Q5NtD5ifNtrSk+cjMpMoDJxW2c/fD38aWq27pWvuiid6bhkSH+P7 WQXkMB2gocxHlXWgAYt1dv8TsX/gKIM0lefx/H8tv68Ssq1W698xgaO5WJN3sKBLcnw+ S3PpQZibrobhvd4yFiF1Ns5B2mWZ0cNcSP/TzCPS8UXxTY2qdPS5nBOZCZNIu0pQ+zkN ieb0pBxK9PtJT3jBJ58Pku9rnQLQX6v3WcsSDbCuYPXanFu1UmY4eaQKx+fYBrX3FqQR MSfg==
X-Gm-Message-State: AJaThX578COzUcqIrdCx6UHDEDtcHLGtypKWiGYWK6TT5HcSyvJ8b1nT 7qJe/SuUtlp8aK1RqnV+7qRXqgn7hQA=
X-Google-Smtp-Source: AGs4zMaDr4Vf9s2GaLEBl35Iiz3byjIOC3kpHo3OMgFBp0LgG/ea1GNscOs1wex7q1yuQvPnvUtqGQ==
X-Received: by 10.159.254.19 with SMTP id r19mr4764146pls.271.1510450856613; Sat, 11 Nov 2017 17:40:56 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:2d46:9871:49ae:c296? ([2001:67c:370:1998:2d46:9871:49ae:c296]) by smtp.gmail.com with ESMTPSA id a78sm18308368pfl.155.2017.11.11.17.40.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 17:40:56 -0800 (PST)
From: Ted Lemon 
Message-Id: <46025DC1-E6BC-4B3E-9423-20CE55B392A6@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F3B5FDEF-8024-46EC-87E5-D515DDD4405E"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 12 Nov 2017 09:40:53 +0800
In-Reply-To: <1510429158.1532491.1169298736.289E12E8@webmail.messagingengine.com>
Cc: babel@ietf.org
To: Justin Kilpatrick 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>      <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com> <877euzqe3r.wl-jch@irif.fr>  <1510429158.1532491.1169298736.289E12E8@webmail.messagingengine.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [babel] About Babel security [was: WG Last Call...]
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Nov 2017 01:40:58 -0000

--Apple-Mail=_F3B5FDEF-8024-46EC-87E5-D515DDD4405E
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On Nov 12, 2017, at 3:39 AM, Justin Kilpatrick  wrote:
> Things like ratelimiting of update requests and sanity checking
> prefixes. There are good questions about what's really necessary and how
> it impacts the standard.

This would be very good.   Can you possibly attend via Meetecho?


--Apple-Mail=_F3B5FDEF-8024-46EC-87E5-D515DDD4405E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 12, 2017, at 3:39 AM, Justin Kilpatrick <justin@altheamesh.com> wrote:
Things like ratelimiting of update =
requests and sanity checking
prefixes. There are =
good questions about what's really necessary and how
it impacts the standard.

This =
would be very good.   Can you possibly attend via =
Meetecho?

=

--Apple-Mail=_F3B5FDEF-8024-46EC-87E5-D515DDD4405E--


From nobody Sat Nov 11 17:45:21 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40572128C83 for ; Sat, 11 Nov 2017 17:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level: 
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6vVc8ZysTVO for ; Sat, 11 Nov 2017 17:45:19 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013E0124BFA for ; Sat, 11 Nov 2017 17:45:19 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5145D20840; Sat, 11 Nov 2017 20:45:18 -0500 (EST)
Received: from web3 ([10.202.2.213]) by compute7.internal (MEProxy); Sat, 11 Nov 2017 20:45:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=YmOdfs Smsvz6AsVbIqLaWtzEnrGLwawrVbV6s0GvRU8=; b=eNBmd0DarWKogwyPz0+uli In6lyw4weTQ7aG8gWafm9RE3vKOhN3A2x89vA19ss+cm6OK/ch3UnAG+i10OV/JX u7eNVrhNdKudCypE4TTKNFX7uvGrewaYAMdwut4R2AUu18VsVPsAhKNAZTe/ePfc gEvrrnog42sgWg3HNxcLMhglcOJOB9ESZveNARx4QdXwJ39xsL0ugnh+9Ii2VzhZ bOekz2bvs76HW9OsSvuPodHSZGei4e8Hi0CghubFf+ooOZTmTjqH9v/oc8Pd2E0o 50TYBsPUElnkECrktIMthrLJcj2xmnHoFf4ybv2XaFiojF24GhfjlvBYQMZrg/QA ==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 335089EDB1; Sat, 11 Nov 2017 20:45:18 -0500 (EST)
Message-Id: <1510451118.1527415.1169492240.53FF46A2@webmail.messagingengine.com>
From: Justin Kilpatrick 
To: Ted Lemon 
Cc: babel@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_151045111815274150"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9
Date: Sat, 11 Nov 2017 20:45:18 -0500
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>      <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com> <877euzqe3r.wl-jch@irif.fr>  <1510429158.1532491.1169298736.289E12E8@webmail.messagingengine.com> <46025DC1-E6BC-4B3E-9423-20CE55B392A6@fugue.com>
In-Reply-To: <46025DC1-E6BC-4B3E-9423-20CE55B392A6@fugue.com>
Archived-At: 
Subject: Re: [babel] About Babel security [was: WG Last Call...]
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Nov 2017 01:45:20 -0000

This is a multi-part message in MIME format.

--_----------=_151045111815274150
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"

That would be great.

--
  Justin Kilpatrick
  justin@altheamesh.com



On Sat, Nov 11, 2017, at 08:40 PM, Ted Lemon wrote:
> On Nov 12, 2017, at 3:39 AM, Justin Kilpatrick
>  wrote:>> Things like ratelimiting of update requests and sanity checking
>> prefixes. There are good questions about what's really necessary
>> and how>> it impacts the standard.
> 
> This would be very good.   Can you possibly attend via Meetecho?
> 

--_----------=_151045111815274150
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="utf-8"







That would be great.





--


  Justin Kilpatrick


  justin@altheamesh.com













On Sat, Nov 11, 2017, at 08:40 PM, Ted Lemon wrote:


On Nov 12, 2017, at 3:39 AM, Justin Kilpatrick <justin@altheamesh.com> wrote:


Things like ratelimiting of update requests and sanity checking


prefixes. There are good questions about what's really necessary and how


it impacts the standard.









This would be very good.   Can you possibly attend via Meetecho?








--_----------=_151045111815274150--


From nobody Sat Nov 11 17:50:07 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAFC128C83 for ; Sat, 11 Nov 2017 17:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4LVcXhf3xw0 for ; Sat, 11 Nov 2017 17:50:03 -0800 (PST)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD59D129412 for ; Sat, 11 Nov 2017 17:50:03 -0800 (PST)
Received: by mail-pf0-x22c.google.com with SMTP id x7so9389390pfa.1 for ; Sat, 11 Nov 2017 17:50:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aKwClEZ2GYsLLJAV3Zt+/BENcGkuPxEESyfMyqRuu1Q=; b=pPm17P2274HMalZjrSN7J6D98ex8XvZ2OS6o9A5EYekmRiRvA5526zfdcn17Nu4ykr 3eMsbdXantN3F1hzo8Qxq1Zz/0mjYZ3Nxb5jAEwz3MN70bTmkHzXSrry3kQYqe8ayawe hKXuuQkyLoq6RzcMljcjNyIL0yVWJgDPWRfh+pHdusMvDCRmHwIyYb+fb1voWY7/cls3 Vy/Mm/U7CI917c06SCN8+STTuSfUcyHER/bQnmfN2keiK2WTvM4bRa8Piukfgib1xoUg avnQk/zrKdT8XUJBiMRJZ3KnwziGMH06qr6SHCTIdv48JyROyR5WbV5r5y7DaaddDS0i dqkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aKwClEZ2GYsLLJAV3Zt+/BENcGkuPxEESyfMyqRuu1Q=; b=dZmNWeMdW16aM41rbCcdyHJg6zSFXs8rvDb60L8MuVxodAth+xHUflbWXwTyeHt8Ef txFgbmp1jt1U2mXaE3K/C/ADD+MLF1iibyduUO8Pn/0KDReN2hlEyht1Yx3P+/0XtG4v rp44h/qwo6zcfdjKvuDyf743bjIxg6ogdp3CsWdTXwBVrcylyTuCIaEWBoNTg8Lc1xC9 W6muJYC/8yQnU5IWK0JtvmHF8KSReAQDwHkwZBwHFQ6EASpZfH+T5jXneEs/zHEujdU5 /lBXxaFVu3If1mecKcOTLJNyeB0zhgtj6L6/TJYsvq53Ze3jT8mE13Wp0I6FDmtAwOAW fmaw==
X-Gm-Message-State: AJaThX5vDFnsjAmqEVflPNhcYuG0Km36pEX8lZtFFXF+d8rJMrKmva6o 59b3K8sxqzkl/SvsfsS9r5vdydKFNfA=
X-Google-Smtp-Source: AGs4zMY3SD3Wh7ED7PE+PekXc+en/+BOkiScib9ruLEvC2uyr3o0uXN8o2P4OtB0agNpWvE1f/l4nA==
X-Received: by 10.98.242.66 with SMTP id y2mr5379010pfl.150.1510451403404; Sat, 11 Nov 2017 17:50:03 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:2d46:9871:49ae:c296? ([2001:67c:370:1998:2d46:9871:49ae:c296]) by smtp.gmail.com with ESMTPSA id m17sm23477655pfh.28.2017.11.11.17.50.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 17:50:02 -0800 (PST)
From: Ted Lemon 
Message-Id: <77E8B5BD-FABC-46D9-9286-D4399B5CA374@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F9A4976B-3944-45D2-B8F0-168D6F09418E"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 12 Nov 2017 09:50:00 +0800
In-Reply-To: <1510451118.1527415.1169492240.53FF46A2@webmail.messagingengine.com>
Cc: babel@ietf.org
To: Justin Kilpatrick 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>      <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com> <877euzqe3r.wl-jch@irif.fr>  <1510429158.1532491.1169298736.289E12E8@webmail.messagingengine.com> <46025DC1-E6BC-4B3E-9423-20CE55B392A6@fugue.com> <1510451118.1527415.1169492240.53FF46A2@webmail.messagingengine.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [babel] About Babel security [was: WG Last Call...]
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Nov 2017 01:50:05 -0000

--Apple-Mail=_F9A4976B-3944-45D2-B8F0-168D6F09418E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 12, 2017, at 9:45 AM, Justin Kilpatrick  =
wrote:
> That would be great.

Wonderful.   Here's the remote participation info: =
https://www.ietf.org/meeting/100/remote-participation.html =


The session starts at 9:30 singapore time: =
https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DBabel&iso=3D20=
171117T0930&p1=3D236&ah=3D2 =




--Apple-Mail=_F9A4976B-3944-45D2-B8F0-168D6F09418E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 12, 2017, at 9:45 AM, Justin Kilpatrick <justin@altheamesh.com> wrote:
That =
would be great.

Wonderful.   Here's the remote participation =
info: https://www.ietf.org/meeting/100/remote-participation.html<=
/div>

The session =
starts at 9:30 singapore time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DBab=
el&iso=3D20171117T0930&p1=3D236&ah=3D2


=

--Apple-Mail=_F9A4976B-3944-45D2-B8F0-168D6F09418E--


From nobody Sat Nov 11 17:50:42 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930EC128C83 for ; Sat, 11 Nov 2017 17:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO_OSKqaNyLj for ; Sat, 11 Nov 2017 17:50:39 -0800 (PST)
Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 BDE94124BFA for ; Sat, 11 Nov 2017 17:50:32 -0800 (PST)
Received: by mail-ot0-x230.google.com with SMTP id j29so7675962oth.13 for ; Sat, 11 Nov 2017 17:50:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/snC62Ptbx78ilMvWwkDW0rRUoXDG/emvgFSTf8LNS4=; b=uXCDt3GFS46SjDID0XBDlPQTFHbU+yVDWHcM06Oytg6OkF9KlKxIInfVWpKsGtcOsE si2lPmdJ4p2v1hdr5zCwjtlyMQUVFuGcs5TuxNtB614Y6tPqd4m2OGF78T0CjNFbaIko HCLQllwO6D8OWVDFQat69zPOwedJLEKBJUxXbckHnZO8zvG/Ns4wRZ5ef3VmGJLz1HQu NhsoFTR6JbmMLGny0TVrOQ6N1WIpzwCUXV2UKDQmbf+FeAEEk63N5sU7YwEH3Rj/lDtz rZREEqk658SZBW6GmBlp3BEt/kWm7uWpNKU4WOZ33Sik8pStzhBC68jd5jCytIeOo1C1 RTqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/snC62Ptbx78ilMvWwkDW0rRUoXDG/emvgFSTf8LNS4=; b=e/49cwE7aN4EgHgE/xCAjwWSuW+2uW8a1Se+YHsRucMcCOYriDrw7Og9vrNIlRO3xj toKK0uRi2fby5vCB0KDT9CMunHLF47TUSxJbNMu2k1aTmL5yOpeBS8X7RcIECimp7C33 fj0celyP61Lj0nqZRnXBaXxE0lvv6nYVvet04PNgLMgzwLFr1721VnywAjrMzJrc21jH 9eyDXPcxZKQZpE36rvAH59Rx/OmcBrz2iGlIMn1JYI0fKDr/Cs3Mqb78UlOeAPQqpIsn y5cV8FbK2ajrRD/ksy4FXki8+UcR9Rbe2Ybj9D4Cjtj3JrJ3jayE5n+/xxnpUho91dSk 1dhg==
X-Gm-Message-State: AJaThX4aR0G6mris/OBqnmXW7/kPxXitF3mY+g1kPznr/gH+sVo7Pt9B 2RKp/CMqlzkRUoNGN7DdHXZiWCnU1G+7sxwPx46QmQ==
X-Google-Smtp-Source: AGs4zMahMdl6vk8LkmLLCDICcq154U00LdvIXZ0MnAPqk+mH8t1ijK+vvYBWg8X8rSMhSNoJN3tCtz9R1mcM2MTu9I0=
X-Received: by 10.157.11.200 with SMTP id 66mr3321629oth.272.1510451431911; Sat, 11 Nov 2017 17:50:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.0.143 with HTTP; Sat, 11 Nov 2017 17:50:31 -0800 (PST)
In-Reply-To: <1510451118.1527415.1169492240.53FF46A2@webmail.messagingengine.com>
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>      <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com> <877euzqe3r.wl-jch@irif.fr>  <1510429158.1532491.1169298736.289E12E8@webmail.messagingengine.com> <46025DC1-E6BC-4B3E-9423-20CE55B392A6@fugue.com> <1510451118.1527415.1169492240.53FF46A2@webmail.messagingengine.com>
From: Alia Atlas 
Date: Sat, 11 Nov 2017 20:50:31 -0500
Message-ID: 
To: Justin Kilpatrick 
Cc: Ted Lemon , Babel at IETF 
Content-Type: multipart/alternative; boundary="001a1135368e0cb53a055dbf6100"
Archived-At: 
Subject: Re: [babel] About Babel security [was: WG Last Call...]
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Nov 2017 01:50:40 -0000

--001a1135368e0cb53a055dbf6100
Content-Type: text/plain; charset="UTF-8"

Justin,

Please do give MeetEcho a try.  It allows very good interactivity/
You do need to pre-register and it's good to run the test program as well
beforehand.

Regards,
Alia

On Sat, Nov 11, 2017 at 8:45 PM, Justin Kilpatrick 
wrote:

> That would be great.
>
> --
>   Justin Kilpatrick
>   justin@altheamesh.com
>
>
>
> On Sat, Nov 11, 2017, at 08:40 PM, Ted Lemon wrote:
>
> On Nov 12, 2017, at 3:39 AM, Justin Kilpatrick 
> wrote:
>
> Things like ratelimiting of update requests and sanity checking
> prefixes. There are good questions about what's really necessary and how
> it impacts the standard.
>
>
> This would be very good.   Can you possibly attend via Meetecho?
>
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>
>

--001a1135368e0cb53a055dbf6100
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Justin,

Please do give MeetEcho a try.=
=C2=A0 It allows very good interactivity/
You do need to pre-regi=
ster and it's good to run the test program as well beforehand.

Regards,
Alia

On Sat, Nov 11, 2017 at 8:45 PM, Justin =
Kilpatrick <justin@altheamesh.com> wrote:






That would be great.





--


=C2=A0 Justin Kilpatrick
=



=C2=A0 justin@altheamesh.com













On Sat, Nov 11, 2017, at 08:40 PM, Ted Lemon wrote:


On Nov 12, 2017, at 3:39 AM, Justin Kilpatri=
ck <justin@al=
theamesh.com> wrote:


Things like ratelimiting of update re=
quests and sanity checking


prefixes. There are good questions about what's really necessary and =
how


it impacts the standard.









This would be very good. =C2=A0 Can you possibly attend via Meetecho?<=
br>








_______________________________________________

babel mailing list

babel@ietf.org

https://www.ietf.org/mailman/listinfo/babel





--001a1135368e0cb53a055dbf6100--


From nobody Sat Nov 11 17:51:39 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71639126D46 for ; Sat, 11 Nov 2017 17:51:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rslaYBs6MK_E for ; Sat, 11 Nov 2017 17:51:37 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 EC7F9124BFA for ; Sat, 11 Nov 2017 17:51:36 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id n89so9373999pfk.11 for ; Sat, 11 Nov 2017 17:51:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BdSr55oKOvHhA/NsAc2L4MYO1Kxeo6hXrECgBNCBeBg=; b=oT15OpbK2a94lBZFLG4m3Vrq4V3TXnIC9eP3IiRGTRSbEscivmfOKa4W/0XyC/atBA O3VxJiux7qsqip/9M3gYkYzCCWLj7ZwBOC+OmTVjNHAgKka2wDPAr4T+283g4IJW2mcM vUQhAOA6es+43aoDcSLHYoPxdc7wRUZ7PdAWUyaecnIdWDwsBp7Pcb71VWqzZCu3cVIv 8g2T9vZLNTTSGLMaOPj8yoasS28UxwFY6kXGvIGpsZDsMVkm4N56ulvtB8NvbEm6nTo9 9Mzb6Fl+Uczcf+nYuIgCZZawKg2SiTBgZOxGs0dX5M2kFkNjlbY6ElMPi0aNyKyafWU5 M4rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=BdSr55oKOvHhA/NsAc2L4MYO1Kxeo6hXrECgBNCBeBg=; b=eOO/1jf8svSgRAxaR1ZvTJxMfAQYEW/W+hoIRrJMaSleRflodZtIw5aG0BwSn4+r6B 1cs6Mn34a7YeltgpW/q1pvRpBcmZ0EXvsxgLbvWxmgofnS1VgBn0cieI8A84mv6UcSob mHPik3mOIf/6lLaa/B0Qb7Mk6+M/pQXW7vk3XWAPdBpXs0SxNY2FUi+IbBDbHEP1wYOO iu1ZKIAYIMHYOFRPZlikJkdEVPSAHKTnVRl2406/Aoo27OwaDwpqODOToc+/zupIs7ba MLvqDHO6gq0kDoXZogDftPNChqAVzXW8BXPqPpdZhUiuKKB4P1de2phcz0jZxbgmmNrZ e6Mg==
X-Gm-Message-State: AJaThX4Yu7jDH1iIUww/WfrcaQkbH7UkEu13gG77m5Hit2hpLv+ulSxj SHoQXZGLbYW5AZIt/yaZjnHAuBH21m8=
X-Google-Smtp-Source: AGs4zMauGYT2l3/adMsLomUKA6xnGQTd6ozd3bUEz6ErWoxkm5Dk+FY52JDvnQGk5FOJtcnSYvWSbw==
X-Received: by 10.98.213.194 with SMTP id d185mr5396843pfg.107.1510451496535;  Sat, 11 Nov 2017 17:51:36 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:2d46:9871:49ae:c296? ([2001:67c:370:1998:2d46:9871:49ae:c296]) by smtp.gmail.com with ESMTPSA id r9sm28002809pfd.6.2017.11.11.17.51.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 17:51:36 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0991F391-94D3-4E33-BCF6-6FCA2E4AAD03"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 12 Nov 2017 09:51:33 +0800
In-Reply-To: <77E8B5BD-FABC-46D9-9286-D4399B5CA374@fugue.com>
Cc: babel@ietf.org
To: Justin Kilpatrick 
References:  <15f6dcf2c8d.e66056b96940.9155266730078596107@ovsienko.info> <871slkb3r3.wl-jch@irif.fr> <15f727f92d8.11e6c3dbd43397.2376860294132856941@ovsienko.info> <87zi87lass.fsf@toke.dk> <15f7353f41b.ffa1d41453323.6020794963079882883@ovsienko.info> <87inevut4p.fsf@toke.dk> <15f786fa6f0.e3f4b0db12167.6625418531640045846@ovsienko.info> <87r2tikl1e.fsf@toke.dk> <15f92044ef7.efa89e885347.7997148307218058093@ovsienko.info> <87y3nhr1gm.fsf@toke.dk> <7ifu9ozskt.wl-jch@irif.fr>   <33EF97A7-BB1B-4B47-83D0-F7F57CC0B0BC@fugue.com>      <0D781858-836D-4811-8E17-23FCC2177EE6@apple.com> <877euzqe3r.wl-jch@irif.fr>  <1510429158.1532491.1169298736.289E12E8@webmail.messagingengine.com> <46025DC1-E6BC-4B3E-9423-20CE55B392A6@fugue.com> <1510451118.1527415.1169492240.53FF46A2@webmail.messagingengine.com> <77E8B5BD-FABC-46D9-9286-D4399B5CA374@fugue.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [babel] About Babel security [was: WG Last Call...]
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Nov 2017 01:51:38 -0000

--Apple-Mail=_0991F391-94D3-4E33-BCF6-6FCA2E4AAD03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 12, 2017, at 9:50 AM, Ted Lemon  wrote:
> The session starts at 9:30 singapore time: =
https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DBabel&iso=3D20=
171117T0930&p1=3D236&ah=3D2 =

BTW, note that if you are in the U.S., this is going to be Thursday =
evening, not Friday evening. :)


--Apple-Mail=_0991F391-94D3-4E33-BCF6-6FCA2E4AAD03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 12, 2017, at 9:50 AM, Ted Lemon <mellon@fugue.com> =
wrote:=

BTW, note that if you are in the U.S., =
this is going to be Thursday evening, not Friday evening. :)

=

--Apple-Mail=_0991F391-94D3-4E33-BCF6-6FCA2E4AAD03--


From nobody Sun Nov 12 09:51:27 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3E3126C89 for ; Sun, 12 Nov 2017 09:51:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.955
X-Spam-Level: 
X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDV1-3pIfN9e for ; Sun, 12 Nov 2017 09:51:24 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4AC12008A for ; Sun, 12 Nov 2017 09:51:24 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A5E8020A81 for ; Sun, 12 Nov 2017 12:51:23 -0500 (EST)
Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Sun, 12 Nov 2017 12:51:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=SJ1z7sK2JwcCdHkoLHd8+A4zZmtIe ycyfOkXU1hgUJw=; b=Nv0SA3CuB6eV3Ls7dewDVnlNwMyIDuu6dxqN7G3+7ocqu 4WnWmtmtIpwCM4QOGGjX3u3XIu+sjGtHUeammEuafDpDMw6RSAKIVdKHjE4YfJqr gMh1yIwc4Bgze/uay56yWtOoOpJWtpPGi7EDgEtt+40/0s+tVKtl6dHfzQVrITwB o+mB2OOybfdLktFIE66XMOgcZTsT6any7Cx6w6vqxvcRIaK7VnlAxdkI1IAaOaoX rHMU/HLlXIT4AZ+T7M5WKLrjoNzCRgpeZw8iItShG3DSb4H8lRFCGvAau/l4EGGz 1egvBjJ7Uo1aeDln31woRpSxkqe1mG5hvd6iRBXTg==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 82A6C6263F; Sun, 12 Nov 2017 12:51:23 -0500 (EST)
Message-Id: <1510509083.1977623.1169822800.55516AAC@webmail.messagingengine.com>
From: Justin Kilpatrick 
To: babel@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9
Date: Sun, 12 Nov 2017 12:51:23 -0500
Archived-At: 
Subject: [babel] Standardizing price advertisements for Babel
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 12 Nov 2017 17:51:26 -0000

I have a half written RFC [0] about how to propagate real-currency
routing prices in Babel. 

You may remember a non-standards compliant version of this I made of
this to familiarize myself with Babel [1]. I posted it to the users list
back in September [2].

While 'one currency to rule them all' is common in blockchain projects I
wanted a more flexible standard. So the prices for the route are moved
to a subtlv on the updates. We also make a new update tlv solely to
carry this subtlv. Otherwise standards compliant Babel instances unaware
of pay-per-forward would ignore the unknown subtlv's and attempt to
route traffic without payment. 

The net effect here is just operating two parallel Babel networks. One
paid and one free, furthermore since currency has to agree along paid
paths there are even more networks within the paid set. 

The main concern here is bloated routing tables. Juliusz has suggested
price aggregation previously [3]. After playing around with a hacky
market simulator [4] I've reached the conclusion that this would be
effective in the common case and easy enough to do on local copies of
the routing tables. But I'm hesitant to build that sort of aggregation
into the network format for complexity reasons.

What I'm most interested in right now is how the community feels about
parallel sets of routing tables and even subtables per currency. Is a
more limited system better simply because a fully utilized arbitrary
currency system would be too inefficient? 

[0]
https://github.com/althea-mesh/babel-drafts/blob/master/draft-ietf-babel-price-propagation/draft-ietf-babel-price-propagation.xml
[1]
https://github.com/althea-mesh/babeld/commit/4e88ef5eab18afcadfdd3739c4637de7e62d76a0
[2]
https://lists.alioth.debian.org/pipermail/babel-users/2017-September/002915.html
[3]
https://lists.alioth.debian.org/pipermail/babel-users/2017-September/002919.html
[4] https://gist.github.com/jkilpatr/ec142833a0c2f09de01b37a83a5f78d2
-- 
  Justin Kilpatrick
  justin@altheamesh.com


From nobody Mon Nov 13 00:01:33 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8161294C9; Mon, 13 Nov 2017 00:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lPK5POV_09L; Mon, 13 Nov 2017 00:01:13 -0800 (PST)
Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 D85EA1294BC; Mon, 13 Nov 2017 00:00:53 -0800 (PST)
Received: by mail-ot0-x231.google.com with SMTP id o23so2093359otd.1; Mon, 13 Nov 2017 00:00:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=QoZV+rYsuW7CTyJPoO4DdTmmFrHLS+ma8D5mItA+upE=; b=W2fyxHQ/h4PbER2RIXk1sxwd3qXd2XBXcvBDtjPCGpt1EWg5i7bZPphWtBLWZJAhq9 f0cQIDy+3ltFL+/vXMV7+wVxMHUOF1MofU4jFo8RvdTakCX8csbg7J9pr6tqxQ7c32aZ zcRwXnCq/NmAe+HxRexN7yaCshciQGCjrMDJ0WCibF3G61nC6Dh+4hjSmJZqKTmanvYU 01u19MJVOszoRNmwx23XC2n8aBHPRCyLYLl8PwoKuevzQgPAXr6l7hx40BTHjOaKx47c 5MJh2KH+6M1c0RAcQsKCDRhodviB9OJugXNZVXAHz8RKRdGjtPuy7c5VvY2rh0rUbW/R l2oA==
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=QoZV+rYsuW7CTyJPoO4DdTmmFrHLS+ma8D5mItA+upE=; b=IgLjUCEznw3YL7SopBOT0mNcbsPIobqxXeDH8ARkP4xDYnkwLgk8/rldy8GcFJOfyg oXOlCT2jMrGegOohzvp44n9Hu9Dx6kjRqjju97f435Sc9U9ChomAgZjeN9QIGmoRMUt3 vaB7pWhUdpBLKuHHEKBvsTSbCw0qOtCdh6BSHFQTpRiP+q2fI0tWuJPqVeek0S2Qfh14 mPygBZZgpd2NSoAEU8HOGHOk8noelmUgrAkfxxGP8y6T1CUDgmA0pKIeScqH28D4prX/ lqtxxcsGnDY8AEm2LQPVbPIVLxCwFtj3UBVKLeZpJtnyko8qe4DRmgUl4LfZtMeBRE6Y ZG+A==
X-Gm-Message-State: AJaThX475qCP6i1snAaI+l1oZayai/JVrGiHQNFrEd1Oz7jjEPxR9cqJ rOmdRDXKTxAH1Hoebfl8w4uBu3aIOXeJ4m0ujRwqOQ==
X-Google-Smtp-Source: AGs4zMbSwoUkd3iM6+vQnk0gq8za7YJ9+Y+KWpGmMTubUOpD2GVz6wYBnP7ZqUEeQx+lNh9OgsAYhRPnv6SV11Y4f2Y=
X-Received: by 10.157.38.248 with SMTP id i53mr5082622otd.94.1510560052940; Mon, 13 Nov 2017 00:00:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.73.194 with HTTP; Mon, 13 Nov 2017 00:00:37 -0800 (PST)
From: Donald Eastlake 
Date: Mon, 13 Nov 2017 03:00:37 -0500
Message-ID: 
To: Babel at IETF 
Cc: babel-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [babel] Would moving the BABEL WG to Thursday afternoon be a problem for anyone?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 08:01:14 -0000

Hi,

There is some desire to move the BABEL WG meeting from the 9:30 to
11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a
problem for anyone?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


From nobody Mon Nov 13 00:13:48 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AF412773A; Mon, 13 Nov 2017 00:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvCtIh177c1T; Mon, 13 Nov 2017 00:13:46 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1A4126B6E; Mon, 13 Nov 2017 00:13:46 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C52B820BF0; Mon, 13 Nov 2017 03:13:45 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 13 Nov 2017 03:13:45 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=LGp4j3ROVNrBMidT8ijD7HcFm/YJy rKVzFw8fR/3DUA=; b=F6/G5BQrG3FJFs9zcJvZocIc21kCsYWO2qNKw57GmnN54 nY/Ia87JOatnra0xS2TYJUHIaMVjhm7iMJjGDHshM5wPBwMknjWiozkmyJK4D7SX nYxPqziDmdGywY9mpW7+/dJjc02Y38JIn0TWnTEp8oZP1//JV72Xt+TabQHnyGRr 3FMvwMqDXQ0VqtHBAiQbxBcxn0OlGywfiUZSoobpUb30C17gqiWsSZJ1QnNHKmLg RtZUw+CvOz6cZ8sdsENH/CmNfD5DVhG5lUzJAkRTZfpDT40WZKLXeR+wZkTXTNVH mx/htw4gAl5qYgXPLNUEgh6134C1GLfTsgTT+ST5Q==
X-ME-Sender: 
Received: from [IPv6:::ffff:31.133.131.142] (dhcp-838e.meeting.ietf.org [31.133.131.142]) by mail.messagingengine.com (Postfix) with ESMTPA id 456587FAC9; Mon, 13 Nov 2017 03:13:44 -0500 (EST)
MIME-Version: 1.0
To: Donald Eastlake , Babel at IETF 
Cc: "babel-chairs@ietf.org" 
From: Russ White 
Date: Mon, 13 Nov 2017 16:12:50 +0800
Importance: normal
X-Priority: 3
In-Reply-To: 
References: 
Content-Type: multipart/alternative; boundary="_13ACC115-5FE2-4842-AF77-2E8E61E4FF34_"
Message-Id: <20171113081344.456587FAC9@mailuser.nyi.internal>
Archived-At: 
Subject: Re: [babel] Would moving the BABEL WG to Thursday afternoon be a problem foranyone?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 08:13:47 -0000

--_13ACC115-5FE2-4842-AF77-2E8E61E4FF34_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"


Great by me.

=F0=9F=98=8A

Russ


Sent from my Windows 10 phone

From: Donald Eastlake
Sent: Monday, November 13, 2017 4:01 PM
To: Babel at IETF
Cc: babel-chairs@ietf.org
Subject: Would moving the BABEL WG to Thursday afternoon be a problem foran=
yone?

Hi,

There is some desire to move the BABEL WG meeting from the 9:30 to
11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a
problem for anyone?

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)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


--_13ACC115-5FE2-4842-AF77-2E8E61E4FF34_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"


 
Great by me.
 
😊=

 
R=
uss
 
=
 
Sent from my Windows 10 phone
 
<=
p class=3DMsoNormal style=3D'border:none;padding:0in'>From: Donald Eastlake
Sent: Monday, No=
vember 13, 2017 4:01 PM
To: Bab=
el at IETF
Cc: babel=
-chairs@ietf.org
Subject: Would moving the BABEL WG to Thursd=
ay afternoon be a problem foranyone?
&nb=
sp;
Hi,
 
There is some desire to move the BABEL WG meet=
ing from the 9:30 to
11:30 slot Friday to the 18:10=
 to 19:10 slot Thursday. Would this be a
problem fo=
r anyone?
 
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=C2=A0=C2=A0 +1-50=
8-333-2270 (cell)
 155 Beaver Street, Milford, MA 0=
1757 USA
 d3e3e3@gmail.com
=
 
=

--_13ACC115-5FE2-4842-AF77-2E8E61E4FF34_--


From nobody Mon Nov 13 00:39:26 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171D012706D for ; Mon, 13 Nov 2017 00:39:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level: 
X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=apple.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 4_DhzImX54Nx for ; Mon, 13 Nov 2017 00:39:22 -0800 (PST)
Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (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 1A0F5126B6E for ; Mon, 13 Nov 2017 00:39:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510562359; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JPBUDfJQhP1ioi2j3L1m4esAc3k24dSlACBrQoLcBvs=; b=Xnfl8IibLa6PfMCsT89Jh26KYBgmG52q7uLcUmeWL2LZXDVV1kYr2ReKfJd+6yn1 83WgU1ovxPhtyNFgSBwq7NzxKrjo9/XKO62ztbc4MfKscvRughAIsPDoTXfts8PZ gjrkF5H2juCo54qr4zwxFlePgJ+RJIJWBZHPBtG1tRIKCrehfnmh9ClCnjTZOMu7 WTKkrHAPPhCb3REEbfts6UYSrPaahxdMx7i7AEBjJOkN2TF/QShlVqLRVK2Aqzco YNazhRZMiRd22LozxnZVwaY2r4YCJ7lsfq6crtpWldxHhYNNrDgqWKZ1LK0+mjTK FIawOBAccX/TwmsJtFCWYA==;
Received: from relay1.asia.apple.com ( [17.82.200.18]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 3B.45.07591.73A590A5; Mon, 13 Nov 2017 16:39:19 +0800 (MYT)
X-AuditID: 1152fe11-cdecd9c000001da7-1d-5a095a379425
Received: from sng-mailphp-s01.asia.apple.com ( [17.84.76.247]) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id 07.E9.23340.73A590A5; Mon, 13 Nov 2017 16:39:19 +0800 (MYT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_S+hTRk9xTFv9g+XyEuxvSw)"
Received: from [IPv6:2001:67c:370:1998:65d8:a56b:a52d:df9a] ([31.130.238.241]) by sng-mailphp-s01.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZC00L58LBVZE30@sng-mailphp-s01.asia.apple.com>; Mon, 13 Nov 2017 16:39:19 +0800 (SGT)
Sender: dschinazi@apple.com
From: David Schinazi 
X-Priority: 3
In-reply-to: <20171113081344.456587FAC9@mailuser.nyi.internal>
Date: Mon, 13 Nov 2017 16:39:22 +0800
Cc: Donald Eastlake , Babel at IETF , "babel-chairs@ietf.org" 
Message-id: <1D0D3C2B-681D-4B6F-B54F-F35F438EA810@apple.com>
References:  <20171113081344.456587FAC9@mailuser.nyi.internal>
To: Russ White 
X-Mailer: Apple Mail (2.3445.1.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42IRDDohpGsexRllMOm8qsXp3lssFlsWdbNY HNyuafGw28SBxWPnrLvsHkuW/GTyOP1wMnsAcxSXTUpqTmZZapG+XQJXxtFjl9kK+nwr7vZs YWtgnOnSxcjBISFgIrG/N7GLkZNDSGAlk8T2A5YgNkh4/eQ7rBDx3YwSZ/5lgti8AoISPybf YwGxmQXCJFZ/e8bYxcgFVLOVSeLjw59sIAlhAWmJrgt3WSHsOIn/s2Yyg+xiE9CSOLDGCGI+ r8SM9qcsIGFOATuJXbdNQcIsAqoSP5e/Z4cYXynRNGshG8RaG4kfm68zQaxqY5SYO+0EWJGI gIzEuvnr2SFmKkocmTmHGaRIQmAPm8TN3etYJjAKz0Jy9ywkd88C2s0soC4xZUouRFhb4sm7 C6wQtprEwt+LmJDFFzCyrWIUz03MzNHNzDPUSyzOTNRLLCjISdVLzs/dxAiOoH+COxinLjQ8 xCjAwajEw3vJnzNKiDWxrLgy9xCjBAezkghvkzdQiDclsbIqtSg/vqg0J7X4EKM0B4uSOG9f 5KdIIYH0xJLU7NTUgtQimCwTB6dUA+PlPo9ovr0a65LMttabTn0glMHTn3pMND8szsBj6rFb vydt7ux+yu8otO/fV5n7UXHqe16d0f5Zfsb7xl+Tnruyj1/zG62r/pw9i/k3P+f5kKPeBYYr 5hSmRnXp3hJ6+kc7+1Xi3JawUv6LnjGlDLo/fk7IMZhj2Xv52s76s4kaJxtSppVI8yixFGck GmoxFxUnAgAy18zRnAIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUiGOLzXdc8ijPKoO22nMXp3lssFlsWdbNY HNyuafGw28SBxWPnrLvsHkuW/GTyOP1wMnsAcxSXTUpqTmZZapG+XQJXxtFjl9kK+nwr7vZs YWtgnOnSxcjJISFgIrF+8h1WEFtIYDejxJl/mSA2r4CgxI/J91hAbGaBMInV354xdjFyAdVs ZZL4+PAnG0hCWEBaouvCXVYIO07i/6yZzF2MHBxsAloSB9YYQcznlZjR/pQFJMwpYCex67Yp SJhFQFXi5/L37BDjKyWaZi1kg1hrI/Fj83UmiFVtjBJzp50AKxIRkJFYN389O8RMRYkjM+cw T2AUmIXk1FlITp0FtI5ZQF1iypRciLC2xJN3F1ghbDWJhb8XMSGLL2BkW8UoWpSak1hpqJdY nJmol1hQkJOql5yfu4kRFPRBJ4R2MH7cb3CIUYCDUYmHN8+XM0qINbGsuDL3EKMEB7OSCG+T N1CINyWxsiq1KD++qDQntfgQozQHi5I4r2bUp0ghgfTEktTs1NSC1CKYLBMHp1QDY5d2IrNW 6lNetW+rrfpYjh95orSU/9pTTbl8ocXf16+NMo3vaNjmrXAuQaAxS+xMyMGJLBeOZCQbSk6/ mO3V73h20+kui7JzoSvKm8xOqYbcv9fJkS44TWB3SpwWq29J29FC2wll9ruYyg/f5lqqbSc2 U+z4xy37VvyfqrtUO2ih5uXiirSdSizFGYmGWsxFxYkAFpjTVHYCAAA=
Archived-At: 
Subject: Re: [babel] Would moving the BABEL WG to Thursday afternoon be a problem foranyone?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 08:39:24 -0000

--Boundary_(ID_S+hTRk9xTFv9g+XyEuxvSw)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

I strongly support this change.

David


> On Nov 13, 2017, at 16:12, Russ White  wrote:
>=20
> =20
> Great by me.
> =20
> =F0=9F=98=8A
> =20
> Russ
> =20
> =20
> Sent from my Windows 10 phone
> =20
> From: Donald Eastlake 
> Sent: Monday, November 13, 2017 4:01 PM
> To: Babel at IETF 
> Cc: babel-chairs@ietf.org 
> Subject: Would moving the BABEL WG to Thursday afternoon be a problem =
foranyone?
> =20
> Hi,
> =20
> There is some desire to move the BABEL WG meeting from the 9:30 to
> 11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a
> problem for anyone?
> =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)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e3e3@gmail.com
> =20
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel


--Boundary_(ID_S+hTRk9xTFv9g+XyEuxvSw)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable

I =
strongly support this change.

David


On Nov =
13, 2017, at 16:12, Russ White <russ@riw.us> wrote:

 
Great by me.
 
=F0=9F=98=8A
 
Russ
 
 
Sent from =
my Windows 10 phone
 
From: Donald Eastlake
Sent: Monday, November 13, =
2017 4:01 PM
To: Babel at IETF
Cc: babel-chairs@ietf.org
Subject: Would moving the BABEL =
WG to Thursday afternoon be a problem foranyone?
 
Hi,
 
There is some desire to move the BABEL WG meeting from the =
9:30 to
11:30 slot Friday to the =
18:10 to 19:10 slot Thursday. Would this be a
problem for anyone?
 
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)
155 Beaver Street, =
Milford, MA 01757 USA
d3e3e3@gmail.com
 
_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel

=

--Boundary_(ID_S+hTRk9xTFv9g+XyEuxvSw)--


From nobody Mon Nov 13 01:04:43 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A9F126CC4 for ; Mon, 13 Nov 2017 01:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wZ_7YypHPC3 for ; Mon, 13 Nov 2017 01:04:30 -0800 (PST)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85E9129503 for ; Mon, 13 Nov 2017 01:04:23 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id i5so11394592pfe.6 for ; Mon, 13 Nov 2017 01:04:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d7+9KbU5D60H8ejt4WXgCzr5t1QmYpftBZMfUxBRKxc=; b=iRRV6OF5zFlVuqQXKxQdCTPc2P7o1F2fUHmn/InmrXmZiox06HDf2tAIkfalsAB2QS kSFbj4J7R/GW1juj/OPrbCtnSXAAXzql31hRbE9Y3cjGSspDpLXoUqyXKqV6sIQWxlgV y4mFpHUDbH0ZOZyjo3AwwFsOYllcGMtwEFCXRY35T5V6yiEO7SiLqCaQaU31WdBWtWpq Oa4WWIQkoktEmx1W1zMheVzegMPMgM2XLHqz0lhD3lKEjtTQ0n/gF/PBZi9eAbv64nad xRawnDl4t4K76ZusihOkCdGlGjCVrjZ/VnmndAuWBhP+qcarfMIAxy2E1DDMBDGh69ZC nT7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d7+9KbU5D60H8ejt4WXgCzr5t1QmYpftBZMfUxBRKxc=; b=VrxdymqFiTK1bZJSBwTCZFFCwQgvs1JpBBVN9o4IeUnG5AoAlgICfDvgHzKeY+yEC2 WmhI9YDQ440n3hRTHQlQikLqUMh5VQ+d8ppyrwrGMlEZvIq2xUH5iQkWUYD7cZCfGnu2 tCL3AxFg1OgJnVvKIJpd1M/M1ir1RNQams5cb1axR0o+4Nn8eWg0JoibVh7e1bCX02r2 I0QHJbpknS/Vr9eKyo+NLbZ9RH4hs24Q2H7Krwrs1BS6HXBL+e00/6tyElYHtdX4Lzft ujSngvbzJ1nl7No0xffpLsNjULTZJRRupGrrGZaMmK5w1+4b7dY0ImnrMunt0izedaPz 1b2w==
X-Gm-Message-State: AJaThX7sfXCITdDHXwsPtnWOxQQqdctKTEgOCb+kULa6+/MRq/gxUAEj Zizu+kbY0tQg9g0R1zPnvQjtY1kl3QdrJg7y6HPgSRLF
X-Google-Smtp-Source: AGs4zMYl1WDq4x8PjGqoV1Uv+4cJIXudjA5qu7Y5h4ufAv7TU4STnAZIqtcUrWstrK0ItAVybXPX/KMO0JtW4UxY14g=
X-Received: by 10.99.177.75 with SMTP id g11mr8065640pgp.326.1510563863019; Mon, 13 Nov 2017 01:04:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.165.5 with HTTP; Mon, 13 Nov 2017 01:03:42 -0800 (PST)
In-Reply-To: <1510509083.1977623.1169822800.55516AAC@webmail.messagingengine.com>
References: <1510509083.1977623.1169822800.55516AAC@webmail.messagingengine.com>
From: Gabriel Kerneis 
Date: Mon, 13 Nov 2017 10:03:42 +0100
Message-ID: 
To: Justin Kilpatrick 
Cc: Babel at IETF 
Content-Type: multipart/alternative; boundary="94eb2c1bec1a780b77055dd98e0f"
Archived-At: 
Subject: Re: [babel] Standardizing price advertisements for Babel
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 09:04:32 -0000

--94eb2c1bec1a780b77055dd98e0f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 12, 2017 at 6:51 PM, Justin Kilpatrick 
wrote:
>
> What I'm most interested in right now is how the community feels about
> parallel sets of routing tables and even subtables per currency. Is a
> more limited system better simply because a fully utilized arbitrary
> currency system would be too inefficient?
>

I don't know anything about pricing routing tables, but I know that you
should in general not try to generalize an idea based on zero example. Do
you have at least one concrete example in mind where such a multi-currency
setup would be useful? If so, it would help inform the discussion if you
could describe it here. Otherwise, it's a strong hint that a more limited
system would be enough. (Also remember that this WG has a tradition of
implementing what it aims at normalizing, and you would need not only to
implement but also test this system=E2=80=94without a use-case, that is goi=
ng to be
tricky.)

Gabriel

--94eb2c1bec1a780b77055dd98e0f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=
On Sun, Nov 12, 2017 at 6:51 PM, Justin Kilpatrick <justin@altheamesh.=
com> wrote:=C2=A0

What I'm most interested in right now is how the community feels about<=
br>
parallel sets of routing tables and even subtables per currency. Is a

more limited system better simply because a fully utilized arbitrary

currency system would be too inefficient?

I don't know anything about pricing routing tables, but I know that =
you should in general not try to generalize an idea based on zero example. =
Do you have at least one concrete example in mind where such a multi-curren=
cy setup would be useful? If so, it would help inform the discussion if you=
 could describe it here. Otherwise, it's a strong hint that a more limi=
ted system would be enough. (Also remember that this WG has a tradition of =
implementing what it aims at normalizing, and you would need not only to im=
plement but also test this system=E2=80=94without a use-case, that is going=
 to be tricky.)

Gabriel


--94eb2c1bec1a780b77055dd98e0f--


From nobody Mon Nov 13 01:08:58 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F89129524 for ; Mon, 13 Nov 2017 01:08:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qldUjtTJcgBJ for ; Mon, 13 Nov 2017 01:08:55 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD006129511 for ; Mon, 13 Nov 2017 01:08:55 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id i5so11401624pfe.6 for ; Mon, 13 Nov 2017 01:08:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K1nraOWP//pLx1pVEtRKHk3ENUnakA1tVjGlHZKWfdA=; b=h0coWngiEFKZJjoEl8lOx1PR8tR490OMTJsUpAWHRFEp53fHWMmnyVYba5In5QnSiN v4sd5A1pS92UnGRVykVPCqgSwyy79Qc2U40ppb799dTxRAn/MS23g8TBGClhu1t9+u+H YPDeuXiRLNeXPr4wbjdEsph9mpOnthh7oX1L6cVWEFNHdZrwNAz9Il7iedw2OQkQHqLK 6lZDRItYVPUNNfhJ1OsQzoXuy7gAWKbDkg/B7ZH0Z83HWpF4eJsLyN0CySk9li+8uhur iAgn9ShSXbHsQE32xo5UOdT5JyDOuSyr2P35ogZuZ7z3G3H6oxfnu6zp/BOuR6h0kjDy An2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K1nraOWP//pLx1pVEtRKHk3ENUnakA1tVjGlHZKWfdA=; b=pHzfTIWFKCUVFX41ygAccwjey6bQdkaWWYl+ds+05VEXwynVTShWBgvpuphCgV+4he LFCmtySL4esXY+d29uOoSWI0ax+DhIXw3kxSXbc4IPAxSMHCKDcxfuzY2J5MacCapg8R Y0BGdKm+4a/c7DYJiTq6YuUnLmiB77TU/1n6YpzEWlpBN45yR8dtKwXDmEJGQwxBiocl ipdOOWSSQx9qX0r8GgG1OfPBR7eEXIG+W4HqU024m4mY6N3Q010I3FHmahP60V9cQffa vsDSckXPO51E8TutlB1XLJIO/8zwYayUvf3CRGsgjQ6OEt9BdvIipaLwRJMRn24wPTbM YJlw==
X-Gm-Message-State: AJaThX5AD7NapyHsuhR4dRLpB/pAs4bgvmwajpdFNN4EWRG1UQ1nq7yU kSB2B420LyXCC/Ws3yb84Oi7Kwp7FvX5WNOtXhfSFfbp
X-Google-Smtp-Source: AGs4zMa4us+xRAyA34ncxOmeorj+oVk6WZ0IDzd2puMT0mfvi+t5LTPa62meU/AVvtYG41pQDqF9YYA6vdyK3QWtRNU=
X-Received: by 10.99.117.90 with SMTP id f26mr8033379pgn.201.1510564135079; Mon, 13 Nov 2017 01:08:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.165.5 with HTTP; Mon, 13 Nov 2017 01:08:14 -0800 (PST)
In-Reply-To: 
References: 
From: Gabriel Kerneis 
Date: Mon, 13 Nov 2017 10:08:14 +0100
Message-ID: 
To: Donald Eastlake 
Cc: Babel at IETF , babel-chairs@ietf.org
Content-Type: multipart/alternative; boundary="f403045ccf90af3c1e055dd99e7e"
Archived-At: 
Subject: Re: [babel] Would moving the BABEL WG to Thursday afternoon be a problem for anyone?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 09:08:57 -0000

--f403045ccf90af3c1e055dd99e7e
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 13, 2017 at 9:00 AM, Donald Eastlake  wrote:

> There is some desire to move the BABEL WG meeting from the 9:30 to
> 11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a
> problem for anyone?
>

To be clear, those are Singapore time right? So we are talking about moving
the meeting to 10:10 UTC?

That would be better for me as well.

Gabriel

--f403045ccf90af3c1e055dd99e7e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=
On Mon, Nov 13, 2017 at 9:00 AM, Donald Eastlake <d3e3e3@gmail.com><=
/span> wrote:
There is some desire to mov=
e the BABEL WG meeting from the 9:30 to

11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a

problem for anyone?

To be clear, those =
are Singapore time right? So we are talking about moving the meeting to 10:=
10 UTC?

That would be better for me as well.
=


Gabriel=C2=A0



--f403045ccf90af3c1e055dd99e7e--


From nobody Mon Nov 13 01:10:58 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1722A129483; Mon, 13 Nov 2017 01:10:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 wWwRHX9YPI1c; Mon, 13 Nov 2017 01:10:55 -0800 (PST)
Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71328126B6E; Mon, 13 Nov 2017 01:10:54 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.44,388,1505772000"; d="scan'208";a="16244014"
From: "Velt, R. (Ronald) in 't" 
To: Donald Eastlake , Babel at IETF 
CC: "babel-chairs@ietf.org" 
Thread-Topic: [babel] Would moving the BABEL WG to Thursday afternoon be a problem for anyone?
Thread-Index: AQHTXFWdewylTw6qmEiWq5BAVe8kn6MSA6SA
Date: Mon, 13 Nov 2017 09:10:52 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.221.225.191]
Old-x-esetresult: clean, is OK
Old-x-esetid: 37303A298D52B26C667D63
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-EsetResult: clean, is OK
X-EsetId: 37303A291940B36C667D63
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [babel] Would moving the BABEL WG to Thursday afternoon be a problem for anyone?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 09:10:57 -0000

Hi,

It would then clash with MANET. (Just noting this. As I cannot be there on =
Friday morning, it is  neither better nor worse for me.)

Ronald

> -----Original Message-----
> From: babel [mailto:babel-bounces@ietf.org] On Behalf Of Donald Eastlake
> Sent: maandag 13 november 2017 9:01
> To: Babel at IETF 
> Cc: babel-chairs@ietf.org
> Subject: [babel] Would moving the BABEL WG to Thursday afternoon be a
> problem for anyone?
> =

> Hi,
> =

> There is some desire to move the BABEL WG meeting from the 9:30 to
> 11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a
> problem for anyone?
> =

> 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)
>  155 Beaver Street, Milford, MA 01757 USA  d3e3e3@gmail.com
> =

> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
This message may contain information that is not intended for you. If you a=
re not the addressee or if this message was sent to you by mistake, you are=
 requested to inform the sender and delete the message. TNO accepts no liab=
ility for the content of this e-mail, for the manner in which you use it an=
d for damage of any kind resulting from the risks inherent to the electroni=
c transmission of messages.


From nobody Mon Nov 13 02:52:53 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DCE128CF0; Mon, 13 Nov 2017 02:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6hg8zK47C-d; Mon, 13 Nov 2017 02:52:50 -0800 (PST)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BD4120726; Mon, 13 Nov 2017 02:52:50 -0800 (PST)
Received: by mail-ot0-x22f.google.com with SMTP id s12so6903842otc.0; Mon, 13 Nov 2017 02:52:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lSOaF4hR/ZNun22lv3bq6hYzL3ngtrmN/f7w4oAtV7o=; b=PaxPhYR3IwTdgBI3fOLRPtsPNkA8ICn4bvUu2Ka0jrGjS8ZmiFejfeJ2csjOhxxJz8 3DH5SR4Xe1nfp00g6hUo1m4fDC7N49aK0TP5H36hgNDcEbUJYx9OXq49ky/PXM3Ci5FC T0TCMZ+e9BpZmE04VQCI5W/pL8k9OiUPprS8yf3iuXGqKMxOtTKukqgVS5bvaxbg+9ch Msj9pIM7/zpYqfph3qhUobnKmxFa+hd3PV8NSqw55ARLtFkas1cK/Ji4i9tmqFIpyzD7 Wnf4hUJxtrTC2Z8r03Qkq1nrWYwyJnoF30x8/oPzszdBvPbDTziv1O9O23b9LH993gOm x1HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lSOaF4hR/ZNun22lv3bq6hYzL3ngtrmN/f7w4oAtV7o=; b=RVx7qBD/uyGLNGHcK7DjIzqHhfE7ZifaE+5gUl6DrLad4iO96QfFpOjgimr/PBfTv/ a7CDZEeLv10wjBetzR/SeBHm5Nesi+Im2KKfsblDdPQGTmzw5549WKxAs4lMiFXYKgvH kRgdZ8ucOSko2rErhdjBAty1WoGqKELOScj7YS9esOoHhhpfouvLLE8QpnqT+/XlGAAB g3AOGnDVgbpF73l2qBaqyL5S/m9dd3E/eSP5dpVepIgQsCR6awjpDQSv3qEEIvtZvX9X 1tlhuTQJB2SaQ3paig6PZzXh5Z2I70r3n7SVybI8GIJuB/LRuA9JLJgY559ON68Ara3O n8Og==
X-Gm-Message-State: AJaThX69/H0CtRl1aLhEgAwHt6Ypnu8xGoNmAxyCmUzkKGejFbEr59Gs ELq0Unnq4GETT+vQ4H8iSCHq6Y4rrJW0SHiiq+w=
X-Google-Smtp-Source: AGs4zMZ09WG1rB/a819dKTv4cCYOn+EOiksj1r5b7Is8BIrysZYMody6tkdMjIu4F38BGWYXgOOUkdQ8a7n6/apPM60=
X-Received: by 10.157.35.42 with SMTP id j39mr4928782otb.167.1510570369997; Mon, 13 Nov 2017 02:52:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.73.194 with HTTP; Mon, 13 Nov 2017 02:52:34 -0800 (PST)
In-Reply-To: 
References:  
From: Donald Eastlake 
Date: Mon, 13 Nov 2017 05:52:34 -0500
Message-ID: 
To: Gabriel Kerneis 
Cc: Babel at IETF , babel-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [babel] Would moving the BABEL WG to Thursday afternoon be a problem for anyone?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 10:52:52 -0000

Yes, the times are Singapore times.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Mon, Nov 13, 2017 at 4:08 AM, Gabriel Kerneis  wrote:
>
> On Mon, Nov 13, 2017 at 9:00 AM, Donald Eastlake  wrote:
>>
>> There is some desire to move the BABEL WG meeting from the 9:30 to
>> 11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a
>> problem for anyone?
>
>
> To be clear, those are Singapore time right? So we are talking about moving
> the meeting to 10:10 UTC?
>
> That would be better for me as well.
>
> Gabriel
>


From nobody Mon Nov 13 03:05:26 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A94012954B; Mon, 13 Nov 2017 03:05:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wvm1NE7551Y3; Mon, 13 Nov 2017 03:05:24 -0800 (PST)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1282129485; Mon, 13 Nov 2017 03:05:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1510571119;  s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=377; bh=yHXDpw2aR+sjh8d3Eg1sxYKAjeW8a+UeWeOTfyVLzwE=; b=E/7b3D7dPnFPPLjwaCfRed49ufsfW5iE8SoAvVbhQO3ttLe2KKKpO0X1ZciRa/Yv zTwkiDJPUX74w3Lh9ITxEKuYnb8Veb5M4PfqQLa5L3zCI9vXn6hyeFOhGWQf2rjG0y/ bwhTE6WdKcQ4hnmfQarIa98c2UFe209W8ezTmEHM=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1510571119420839.4957490971925; Mon, 13 Nov 2017 03:05:19 -0800 (PST)
Date: Mon, 13 Nov 2017 11:05:19 +0000
From: Denis Ovsienko 
To: "Babel at IETF" 
Cc: 
Message-ID: <15fb50e133b.1033dcb877317.1988581758442576531@ovsienko.info>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: 
Subject: Re: [babel] Would moving the BABEL WG to Thursday afternoon be a problem for anyone?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 11:05:25 -0000

---- On Mon, 13 Nov 2017 08:00:37 +0000 Donald Eastlake wrote ---- 
 > Hi, 
 >  
 > There is some desire to move the BABEL WG meeting from the 9:30 to 
 > 11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a 
 > problem for anyone? 

Considering my current time zone, it would not be a problem -- quite the opposite.

-- 
    Denis Ovsienko



From nobody Mon Nov 13 04:18:06 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8B7128D64 for ; Mon, 13 Nov 2017 04:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level: 
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDp0rwZ_Gi8L for ; Mon, 13 Nov 2017 04:18:02 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4F9128959 for ; Mon, 13 Nov 2017 04:18:02 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B155E20E7B; Mon, 13 Nov 2017 07:18:01 -0500 (EST)
Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Mon, 13 Nov 2017 07:18:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UiIxfC r7PGRt6NyrbF7LY3BypnOB0qTJxmapN69v/AA=; b=SQNPsIHTsB4bPj+yxIFyJ6 dRnpyfaM0DxZc42mWmAi4FN6MJvKXR1NqbijO5CN0X06UQCQUDfRq3OmNAvbmp7V fPkfelfgwt4UjkhxDpR7e2xmJnjyBGn7o2tegLUjm8LmY4B0w3GInBaqY0xh5H8W Xk3X3ufQlN3Jc1KDlQ5TYihIz4Ml8xTvLPYXrVlaz8rqdnIljp130TNMC/E0Q+xM 4GiZqoWNNlX4oSL4utc3eiEvmTzFAz6khcI48HWofGbE6HqHmRrzH6SKOmXOzWZ5 n0aRl7iVUPjZpvPEFe6KVuUKlcbRfQoFWgoNymAi6NHzy2s6DLyQ2Yc/22wWd5zw ==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 91F036263F; Mon, 13 Nov 2017 07:18:01 -0500 (EST)
Message-Id: <1510575481.3930192.1170650464.594F3E68@webmail.messagingengine.com>
From: Justin Kilpatrick 
To: Gabriel Kerneis 
Cc: Babel at IETF 
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9
Date: Mon, 13 Nov 2017 07:18:01 -0500
References: <1510509083.1977623.1169822800.55516AAC@webmail.messagingengine.com> 
In-Reply-To: 
Archived-At: 
Subject: Re: [babel] Standardizing price advertisements for Babel
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 12:18:05 -0000

Ah thanks for pointing that out. So right now we envision using a
dollar-coin or some other national currency backed crypto to pay for
traffic in the mesh.

Because handing devices to non-technical people that expose them to the
volatility of cryptocurrency isn't really useful or ethical. What do we
tell them when their internet tokens are worth half of what they where
worth yesterday?

On the other hand if people want to exchange in more traditional and
speculative cryptocurrency that's their choice.=20

As another consideration, what if we iterate the rules of billing so
dramatically that the entire path needs the new system to operate? At
that point we would make a new currency code for the same currency
because the way it is exchanged is different enough that it needs to be
versioned.=20

Previously I had separate 8bit fields for a payment rules version and a
8bit currency code, but 256 rules updates seems too many and 256
possible currencies seems too few.=20

The usecases don't provide a compelling reason to need more than maybe 4
- 8 currency sub-tlv's. Assuming two or three major methods of exchange
and two sets of billing rules active for each as an update rolls out.
Perhaps the number can simply be arbitrarily limited?=20=20

--
=C2=A0 Justin Kilpatrick
=C2=A0 justin@altheamesh.com



On Mon, Nov 13, 2017, at 04:03 AM, Gabriel Kerneis wrote:
>=20
> On Sun, Nov 12, 2017 at 6:51 PM, Justin Kilpatrick  wrote:=C2=A0
>> What I'm most interested in right now is how the community feels about
>>  parallel sets of routing tables and even subtables per currency. Is a
>>  more limited system better simply because a fully utilized arbitrary
>>  currency system would be too inefficient?
>=20
> I don't know anything about pricing routing tables, but I know that you s=
hould in general not try to generalize an idea based on zero example. Do yo=
u have at least one concrete example in mind where such a multi-currency se=
tup would be useful? If so, it would help inform the discussion if you coul=
d describe it here. Otherwise, it's a strong hint that a more limited syste=
m would be enough. (Also remember that this WG has a tradition of implement=
ing what it aims at normalizing, and you would need not only to implement b=
ut also test this system=E2=80=94without a use-case, that is going to be tr=
icky.)
>=20
> Gabriel


From nobody Mon Nov 13 07:28:35 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08AF129AC9 for ; Mon, 13 Nov 2017 07:28:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F-CR-6g7QkK for ; Mon, 13 Nov 2017 07:28:32 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F47129449 for ; Mon, 13 Nov 2017 07:28:31 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vADFSQUE024057; Mon, 13 Nov 2017 16:28:27 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 069EAEB216; Mon, 13 Nov 2017 16:28:27 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KzPrvZ2OrJ5x; Mon, 13 Nov 2017 16:28:25 +0100 (CET)
Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E74A5EB217; Mon, 13 Nov 2017 16:28:25 +0100 (CET)
Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1eEGev-0004yk-Lk; Mon, 13 Nov 2017 16:28:25 +0100
Date: Mon, 13 Nov 2017 16:28:25 +0100
Message-ID: <7ishdi5hba.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: Justin Kilpatrick 
Cc: babel@ietf.org
In-Reply-To: <1510509083.1977623.1169822800.55516AAC@webmail.messagingengine.com>
References: <1510509083.1977623.1169822800.55516AAC@webmail.messagingengine.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 13 Nov 2017 16:28:27 +0100 (CET)
X-Miltered: at korolev with ID 5A09BA1A.00D by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A09BA1A.00D 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 : 5A09BA1A.00D 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] Standardizing price advertisements for Babel
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 15:28:34 -0000

> While 'one currency to rule them all' is common in blockchain projects I
> wanted a more flexible standard. So the prices for the route are moved
> to a subtlv on the updates.

Makes sense.  (Note that you called your field "price per byte" -- what if
a given pricing model involves "price per packet" or "price per unit of
airtime"?).

> We also make a new update tlv solely to carry this subtlv. Otherwise
> standards compliant Babel instances unaware of pay-per-forward would
> ignore the unknown subtlv's and attempt to route traffic without
> payment.

That's true in RFC 6126.  In rfc6126bis, there is a new feature, the
mandatory bit, which is designed to handle cases exactly like this one.
If an unknown mandatory sub-TLV is encountered, the whole enclosing TLV is
dropped, just like you suggest.

However, I'm not sure that this is the right approach.  I would suggest
that you use a normal Update carrying the metric of the free path, and
a sub-TLV that carries both the cost and the metric of the paid route.  If
a given node does not advertise a free route, the TLV's metric is set to
infinity.

In short:

  your encoding:   >

  suggested encoding: >

and

  your encoding: >

  suggested encoding >

> The net effect here is just operating two parallel Babel networks.

I think this statement is ambiguous, and I suggest you remove it from your
draft.  There's just one set of neighbour relationships, and the router
carry two parallel sets of updates.

> What I'm most interested in right now is how the community feels about
> parallel sets of routing tables and even subtables per currency.

Babel has had the ability to carry mutliple sets of routes since very
early in its history -- it was originally an IPv6-only protocol, but
learned to carry IPv4 a mere few months after its inception (we were doing
IPv4-in-IPv6 tunnels before it was fashionable).  Both the source-specific
and ToS-specific extensions can be modelled as using multiple tables.

Another point.  Perhaps I've missed something, but you don't seem to
define the semantics of a single Update carrying multiple Pay sub-TLVs.
Does it mean that you get to (1) pay one of those, at your choise, (2) pay
one of those, at the network's choice, or (3) the sum?  I think this
deserves defining precisely.

-- Juliusz


From nobody Mon Nov 13 07:49:46 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208AF129B04; Mon, 13 Nov 2017 07:49:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 iECSvMzZKCfH; Mon, 13 Nov 2017 07:49:42 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7F9129B03; Mon, 13 Nov 2017 07:49:42 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vADEGVhk016083; Mon, 13 Nov 2017 09:22:39 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2e76t5evjn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Nov 2017 09:22:38 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vADEMbLR026922; Mon, 13 Nov 2017 09:22:37 -0500
Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vADEMWSP026876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Nov 2017 09:22:32 -0500
Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 13 Nov 2017 14:22:12 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 09:22:11 -0500
From: "STARK, BARBARA H" 
To: Donald Eastlake 
CC: Babel at IETF , "babel-chairs@ietf.org" 
Thread-Topic: [babel] Would moving the BABEL WG to Thursday afternoon be a problem for anyone?
Thread-Index: AQHTXFWfFl7rmDPk9kG+k72Cv+dTW6MSXOuF
Date: Mon, 13 Nov 2017 14:22:11 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-13_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711130200
Archived-At: 
Subject: Re: [babel] Would moving the BABEL WG to Thursday afternoon be a problem for anyone?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 15:49:44 -0000

I support the move.=20
Barbara

> On Nov 13, 2017, at 4:01 PM, Donald Eastlake  wrote:
>=20
> Hi,
>=20
> There is some desire to move the BABEL WG meeting from the 9:30 to
> 11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a
> problem for anyone?
>=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)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e3e3@gmail.com
>=20
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm=
an_listinfo_babel&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8T=
q4vrfog&m=3DdwS2A02EHn-mbdyJc8BEd0ZrvIL8h7aIp-HrDdfCeYk&s=3DR9VypfgGFsXUo9a=
b23bLQoIh6pxorxxoRLGUgD1QvCQ&e=3D=20


From nobody Mon Nov 13 13:50:56 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D57126C2F for ; Mon, 13 Nov 2017 13:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level: 
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGw9Je3qIzzo for ; Mon, 13 Nov 2017 13:50:30 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FED4120724 for ; Mon, 13 Nov 2017 13:50:30 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D048121070; Mon, 13 Nov 2017 16:50:29 -0500 (EST)
Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Mon, 13 Nov 2017 16:50:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=tHJZ56 jlxyVlM7x4f/XRMPioM/7PZ7tu5vkKzwZPhLA=; b=dBKmEgIXGmsICIylQfhy/z o+cMX02X3WQdluoQD0m5BZH7wUXwdO/mIhKoqbe1fgu6C2gEoyUVgGHltH33h+Fu Z3SVhGv4XrKlJ29YUtpNs5vZhwI7zL0gAYaU5muvVESdGUP196hxMfCwQ/Sx0+Wz W8BJ3NwIDXsFpI6GRW4yHI8/TTi2N1vRxtt8Z8gnZCcfRDa7H3SufsQgmZY5tAt2 dytjMQhmeLWxft6wyXuUsHdK40rHZAMVYJVEceQJWnjQ9NCTMg8S6WV0VvV4PuWi oPl388D7yTpktuFaBJCiMJ4fBeCucOKLKEOKo4gLSniMvu3X6Y0KxT7qdXDOCy/Q ==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id A84FF6263F; Mon, 13 Nov 2017 16:50:29 -0500 (EST)
Message-Id: <1510609829.2245854.1171284136.5838D3F7@webmail.messagingengine.com>
From: Justin Kilpatrick 
To: Juliusz Chroboczek 
Cc: babel@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9
Date: Mon, 13 Nov 2017 16:50:29 -0500
In-Reply-To: <7ishdi5hba.wl-jch@irif.fr>
References: <1510509083.1977623.1169822800.55516AAC@webmail.messagingengine.com> <7ishdi5hba.wl-jch@irif.fr>
Archived-At: 
Subject: Re: [babel] Standardizing price advertisements for Babel
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 13 Nov 2017 21:50:56 -0000

On Mon, Nov 13, 2017, at 10:28 AM, Juliusz Chroboczek wrote:
> Makes sense.  (Note that you called your field "price per byte" -- what
> if
> a given pricing model involves "price per packet" or "price per unit of
> airtime"?).

Now that I think about it that's a terminology error. Written before I
had the idea for billing methods being part of the spec.

There's no reason not to allow for packet or airtime billing at that
point. I will correct that. 

> That's true in RFC 6126.  In rfc6126bis, there is a new feature, the
> mandatory bit, which is designed to handle cases exactly like this one.
> If an unknown mandatory sub-TLV is encountered, the whole enclosing TLV
> is
> dropped, just like you suggest.
> 
> However, I'm not sure that this is the right approach.  I would suggest
> that you use a normal Update carrying the metric of the free path, and
> a sub-TLV that carries both the cost and the metric of the paid route. 
> If
> a given node does not advertise a free route, the TLV's metric is set to
> infinity.
> 
> In short:
> 
>   your encoding:      cost=93>>
> 
>   suggested encoding: >
> 
> and
> 
>   your encoding: >
> 
>   suggested encoding >

This does provide more backwards compatibility since any version of
Babel will discard the update as infeasible regardless of 6126bis. So
long as we are limited to no more than a couple currency subtlv's per
update it should be an acceptable amount of duplicate information. 

> I think this statement is ambiguous, and I suggest you remove it from
> your
> draft.  There's just one set of neighbour relationships, and the router
> carry two parallel sets of updates.

ack, will do. 

> Another point.  Perhaps I've missed something, but you don't seem to
> define the semantics of a single Update carrying multiple Pay sub-TLVs.
> Does it mean that you get to (1) pay one of those, at your choise, (2)
> pay
> one of those, at the network's choice, or (3) the sum?  I think this
> deserves defining precisely.

I see this as a billing advertising spec. The currency code is
interpreted by a billing program that does the actual payments and
follows it's own (as of yet unwritten) standard protocol. 

That being said maybe I removed too much when I decided to separate that
out. 

Both 1 and 2 are options. With 2 the entire path must agree on a
currency and you don't need to concern yourself with having scratch
money to pay suppliers. There's no reason to disallow (1) but then it's
on the billing implementation to potentially juggle currencies. 

For example lets say you don't go with the currency code advertised for
the path and instead add a few others. Then someone may pay you in
currency A where you have to pay the next hop in currency B. It's
possible you will run out of currency B and have to get more somewhere.
Hopefully using currency A that you just earned. Not to mention it's
possible to accidentally use an out of date exchange rate and end up
subsidizing the connection. 

Considering the added complexity on the part of the billing
implementation it may be better to simply ban (1).


Thanks for the feedback.

-- 
  Justin Kilpatrick
  justin@altheamesh.com

On Mon, Nov 13, 2017, at 10:28 AM, Juliusz Chroboczek wrote:
> > While 'one currency to rule them all' is common in blockchain projects I
> > wanted a more flexible standard. So the prices for the route are moved
> > to a subtlv on the updates.
> 
> Makes sense.  (Note that you called your field "price per byte" -- what
> if
> a given pricing model involves "price per packet" or "price per unit of
> airtime"?).
> 
> > We also make a new update tlv solely to carry this subtlv. Otherwise
> > standards compliant Babel instances unaware of pay-per-forward would
> > ignore the unknown subtlv's and attempt to route traffic without
> > payment.
> 
> That's true in RFC 6126.  In rfc6126bis, there is a new feature, the
> mandatory bit, which is designed to handle cases exactly like this one.
> If an unknown mandatory sub-TLV is encountered, the whole enclosing TLV
> is
> dropped, just like you suggest.
> 
> However, I'm not sure that this is the right approach.  I would suggest
> that you use a normal Update carrying the metric of the free path, and
> a sub-TLV that carries both the cost and the metric of the paid route. 
> If
> a given node does not advertise a free route, the TLV's metric is set to
> infinity.
> 
> In short:
> 
>   your encoding:      cost=93>>
> 
>   suggested encoding: >
> 
> and
> 
>   your encoding: >
> 
>   suggested encoding >
> 
> > The net effect here is just operating two parallel Babel networks.
> 
> I think this statement is ambiguous, and I suggest you remove it from
> your
> draft.  There's just one set of neighbour relationships, and the router
> carry two parallel sets of updates.
> 
> > What I'm most interested in right now is how the community feels about
> > parallel sets of routing tables and even subtables per currency.
> 
> Babel has had the ability to carry mutliple sets of routes since very
> early in its history -- it was originally an IPv6-only protocol, but
> learned to carry IPv4 a mere few months after its inception (we were
> doing
> IPv4-in-IPv6 tunnels before it was fashionable).  Both the
> source-specific
> and ToS-specific extensions can be modelled as using multiple tables.
> 
> Another point.  Perhaps I've missed something, but you don't seem to
> define the semantics of a single Update carrying multiple Pay sub-TLVs.
> Does it mean that you get to (1) pay one of those, at your choise, (2)
> pay
> one of those, at the network's choice, or (3) the sum?  I think this
> deserves defining precisely.
> 
> -- Juliusz


From nobody Mon Nov 13 16:35:41 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0924E128954; Mon, 13 Nov 2017 16:35:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCv5g2teq_ab; Mon, 13 Nov 2017 16:35:38 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 B34E81200CF; Mon, 13 Nov 2017 16:35:38 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id b17so3175228oth.2; Mon, 13 Nov 2017 16:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qo3hPolMvIJCjNX9lQ2BA3RyonfyJ3w5YeGa7zs0ojs=; b=Q0JLK4AIAijs2xA3c95Hoe9ZYzST3RjgpMBh6qV/68GAUajcPpq6uRxUUsiblX/NK+ AbZoqO+E7Zd4fbOQbxK3U9GHA8YoMDnaXpajRdFdQIZptIRHY2ZDaNGCqI6s4tpwsvWw CceTRWg2skPX72fgezPp6gR3fc+ORPSQeeDx4GZvz7RNrrw6oQlen4GDMRZ77UyUxOou RIHNfkXkRgukGImYISAesfe9arxhjj27fJX2FXpR/JKjxzd8pIJLWobSr6GQUmetPQhs phXaOLJWPI5wCDgWH+V0WlcrJgH2nAWQggfQhUNVedj4thpeUHqKtCuRP5tCJD63P9Em ODjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qo3hPolMvIJCjNX9lQ2BA3RyonfyJ3w5YeGa7zs0ojs=; b=jWKfd8/ewCTvTZHCt0km1HOog4D+JfylQhu6H37ftxq/2eGcm7B60SGyOG37Q4Cz65 S5jXcIuWwNEQz/09MpFXUYgONivqOCs8hH53x5yCMd9EZ1A0pF9WcTrU0hEMgX7Rb0K4 29jfRN7fgabu88h6RGFTxrbtsUuErQXyyaI8lg5lk+O7SkAbVMKb64u8Ml8LbpOaEv1h pPezJGAlWp3mTb2f7btVAGdei7JhKHNcrYEM3yiD6ihosvxmw4OeM+wHKc7cWW+k3tSk UNRsmXtNOmk00h7j6OD2XDO6SvWMUyVr8TeL5jaI4pmul7U7asIzkX+0Ak+AozI3KH/C 9u1Q==
X-Gm-Message-State: AJaThX6yMgoTx9UXiTgWVygJ3jvDDd8RcXFhlGWEu8E4R2hlDekDCMiy B1t6T1Aa+Nzax2yWwOmPuI5p5cHyo8hC0b5P+Abuog==
X-Google-Smtp-Source: AGs4zMa7+VmG39/t1AHlCh2zmB4e1yRTkZH9tqlF63KNfuYZ0hTpkppxip6fR+YzfHlEQ7EfhFnChpyGlKkvOrpEm0c=
X-Received: by 10.157.87.44 with SMTP id p41mr7059806oth.395.1510619737787; Mon, 13 Nov 2017 16:35:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.73.194 with HTTP; Mon, 13 Nov 2017 16:35:22 -0800 (PST)
In-Reply-To: 
References: 
From: Donald Eastlake 
Date: Mon, 13 Nov 2017 19:35:22 -0500
Message-ID: 
To: Babel at IETF 
Cc: babel-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [babel] Would moving the BABEL WG to Thursday afternoon be a problem for anyone?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 00:35:40 -0000

Since support is overwhelming, expect the Babel meeting to move to
Thursday afternoon, 18:10 to 19:10 Singapore time.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Mon, Nov 13, 2017 at 3:00 AM, Donald Eastlake  wrote:
> Hi,
>
> There is some desire to move the BABEL WG meeting from the 9:30 to
> 11:30 slot Friday to the 18:10 to 19:10 slot Thursday. Would this be a
> problem for anyone?
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com


From nobody Tue Nov 14 22:29:22 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F671243F6; Tue, 14 Nov 2017 22:29:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 lbiMdCBfcUGU; Tue, 14 Nov 2017 22:29:20 -0800 (PST)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 F362B128B88; Tue, 14 Nov 2017 22:29:19 -0800 (PST)
Received: by mail-oi0-x22a.google.com with SMTP id a75so9745659oib.1; Tue, 14 Nov 2017 22:29:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=hSBLDk9O5D3WO6oFnxiFSct+IeQb0PgknrDYyhRppV0=; b=sNfzW1uGl1bKnjsQT9GnmTaeI4Q4C994PKj6HXChnwym/QbPWNMo1C/nxOEkSrIO+d mqiaL0tj1ef/UCQVcT/nEqj8NsHsusvOtJ7zwaKAMQfhTxNIj9jGgK3DlkivBVR7K0l2 A3N+RPXoc0YIA58ZiUeZ7Y/5YblCyZiw6aQ2/yaOtCi3kBGE6u5Z9qlJJX2Xx5D50HG/ VvKXq0d0eDoIruNNVA/ukibwF7dSmnVK/t06BB88gn3NW+f4o7mpxhj+hhw9S10nwN+u p5xu3ZfXuDPcLvAYopOOXuISHztHcq/wD8udTSrMuZAZ1gxYTf4rowYcje3loGG38g1d UtKw==
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=hSBLDk9O5D3WO6oFnxiFSct+IeQb0PgknrDYyhRppV0=; b=h3OXMgSx+fns0C3Wp1k/+DbkBHy8qhwKLhzLZle3zaDEk6mZ7Nux6+ihH8q0VsbFQY d8vFtqNp6In/RyET/ZZreeQZDEv2j5+h1Zsnqpitbp/BHhiYY+pI7BO5RK/+QJK21dDZ /uyg5Rt0Anuh4fvgP3sYILxrQATWOwaqHoFRgXpb0jHR5MW/Zpe7h0fgGelRiol5Eraw vbUbUyCD4Xb3TyrOQ01ZMQDb9EggD48wdLqFqLrQ6wDf1kkrd3ykdO0+7G6S32zVMJlq AV1jdAndF/RD+43Oi9r+a4+lCpuJKLHXmQNbOORXoEqNEPJkl93k881venJoAEROTDnb mu8Q==
X-Gm-Message-State: AJaThX5PCq3oB84NO/XoLwawQndXSWNq2lGj3G9xnjhZGFpsNURqz2QV 5yR2+OgL3MAmPFurJESpvZjpYtENyC+d7p8HwqheYA==
X-Google-Smtp-Source: AGs4zMa3gmVviTe8zV1YO/PqXlVpi4VLs+xk52Op07FK8M1pXOMfV7xqP98Db+tC3ImcMAOcMFFP1WBAZLid+eDnI8c=
X-Received: by 10.202.80.8 with SMTP id e8mr5863710oib.152.1510727359042; Tue, 14 Nov 2017 22:29:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.73.194 with HTTP; Tue, 14 Nov 2017 22:29:03 -0800 (PST)
From: Donald Eastlake 
Date: Wed, 15 Nov 2017 01:29:03 -0500
Message-ID: 
To: Babel at IETF 
Cc: babel-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [babel] BABEL WG meeting has been move to Thursday,
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 15 Nov 2017 06:29:21 -0000

Hi,

The BABEL WG meeting at the Singapore IETF meeting this week has been
moved from Friday morning to the 18:10 to 19:10 time slot Thursday
afternoon (Singapore time). It will be in the Bras Basah Room.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


From nobody Wed Nov 15 06:34:17 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CAF12711D for ; Wed, 15 Nov 2017 06:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG8SPIaGaDnk for ; Wed, 15 Nov 2017 06:34:12 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8911812025C for ; Wed, 15 Nov 2017 06:34:11 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAFEY96e003640; Wed, 15 Nov 2017 15:34:09 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2AD18EB215; Wed, 15 Nov 2017 15:34:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 3S5TdsRBHVf0; Wed, 15 Nov 2017 15:34:04 +0100 (CET)
Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7AC9BEB217; Wed, 15 Nov 2017 15:34:02 +0100 (CET)
Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1eEylO-0003VR-Fl; Wed, 15 Nov 2017 15:34:02 +0100
Date: Wed, 15 Nov 2017 15:34:02 +0100
Message-ID: <7ia7zn6279.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: babel-users@lists.alioth.debian.org
CC: babel@ietf.org
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 15 Nov 2017 15:34:09 +0100 (CET)
X-Miltered: at korolev with ID 5A0C5061.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A0C5061.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 : 5A0C5061.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] Babel@ietf meeting on Thursday: remote participation
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 15 Nov 2017 14:34:15 -0000

Dear all,

This is to remind you that the Babel meeting will be tomorrow (Thursday):

  18:10 SGT (Singapore)
  11:10 CET (Paris, Warsaw)
  10:10 UTC
  05:10 EST (New York, NY)
  02:10 PST (Vacaville, CA)

If you have a reasonably recent web browser, remote participation is easy:

1. register here (you can do that in advance):

    https://www.ietf.org/meeting/remote-registration.html

2. join us here (at the time of the meeting):

    https://brasbasah.conf.meetecho.com/q-meetecho/login.jsp?ietf=babel

You don't need a webcam or a microphone, you can participate in the
discussion in writing and a friendly scribe will read out your
contribution.  If you prefer to lurk, you're very much welcome.

The agenda is here, and a copy of the slides will be uploaded as soon as
we're ready (grep for Babel):

    https://datatracker.ietf.org/meeting/agenda/

Highlights:

  - David Schinazi will speak about the recent evolution of the protocol;
  - Juliusz Chroboczek will open the security discussion;
  - Zheng (Sandy) Zhang will speak about BIER over IPv6.

BIER is a technology for multicast forwarding that doesn't require
per-session state in every router, and therefore has a chance of getting
deployed.  Sandy and her team have been working on using Babel as the BIER
control protocol.  The introduction to BIER is rather readable:

  https://tools.ietf.org/html/draft-ietf-bier-architecture

Hope to see you tomorrow,

-- Juliusz Chroboczek


From nobody Thu Nov 16 02:23:42 2017
Return-Path: <7riw77@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC241200CF for ; Thu, 16 Nov 2017 02:23:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0H9dBb_xvkA for ; Thu, 16 Nov 2017 02:23:39 -0800 (PST)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148CF120046 for ; Thu, 16 Nov 2017 02:23:39 -0800 (PST)
Received: by mail-pf0-x233.google.com with SMTP id r62so6707478pfd.5 for ; Thu, 16 Nov 2017 02:23:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=nHVesSjBXHMLU4AQS9xsW1N0K5XmBJ0g33I+Vot0RuI=; b=YMFjKqC3kpGkS4W4zCgVlfkDvVRzHU6V45DlMiImK5gTqcwA2B6ljRqRnfeLBf5lmi g4lpqf1k+JpFL/ZI3+M7/x7J0OzuC/LDUO3lkLXk28o18lVJc3T+9SMhSGTiQBCYcHsh 7IzI+TzIdyTnGvtyszFiGBb8RdZIShvZta3aV0Pqv0BQjGEp+TEE+9470BTMPU3gVYt6 vmK8zljYOyi3R3b9rBr6zTJS8WIofzQh3lwoBNPM/bWb46XJoTXLz2yWGAQBbKte1J86 W7vRVUQnaGhYjrYn2m35EcDumZqQT0iUvlYabktnccxqSl2ucra64CRHKvMIja18tS8Q w67g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=nHVesSjBXHMLU4AQS9xsW1N0K5XmBJ0g33I+Vot0RuI=; b=G+8AL3wjJFj1/Z/k+4lzPPo9/qeEDtbRM/9JRNzaKXT95MUtdqKuHJLeZ078oHX/CO bs5YlAowVUVS160oBfiPC4XVqHTJljHJIDkmtshqMekDY2XKlAeNP8q5FvTlgX4GRdkl 584FAsCDEtD26F1x+W3u5sIqxlLA/H/0mUUGQyYUuWZ0h/Utcix+NtSVdxGggubONm8N cghWy0ii0hjarpr8LGGOYga3SBjxyv8uwSo+mGXE/36le7nk2BvYqFxdHgv4T0W0lzP9 ct5Fw/+iKGBMQ6ZTBol2BswJ5up+w3GoGldVJRarK1dEgl7JnVoPaZbqa8diZ5D2+fsL mLtQ==
X-Gm-Message-State: AJaThX55bF6HCtsfAomrvreQTMjdDBkk45dhWFYYTI41i4Koe1A05zEA Sya9GViWQon6SDgE9x0Iqr4uPA==
X-Google-Smtp-Source: AGs4zMaJQFlnbYUGX5zarnDDl3oRl1FEz8Gz3grQO5cL0U70zcQztJI6Tk11qjB+MzXjdc128Xu9BQ==
X-Received: by 10.98.237.5 with SMTP id u5mr1287692pfh.209.1510827818405; Thu, 16 Nov 2017 02:23:38 -0800 (PST)
Received: from Russ ([2001:67c:370:128:bde2:c0af:6931:cdf8]) by smtp.gmail.com with ESMTPSA id e9sm1799501pgt.66.2017.11.16.02.23.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 02:23:38 -0800 (PST)
From: "Russ White" <7riw77@gmail.com>
To: "'Juliusz Chroboczek'" , 
Cc: 
Date: Thu, 16 Nov 2017 05:23:32 -0500
Message-ID: <006701d35ec4$f59cc7d0$e0d65770$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdNexKXf90E2f0+rSZmp+Lc3yCMgoQ==
Content-Language: en-us
Archived-At: 
Subject: [babel] History of Babel on The Network Collective --
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 16 Nov 2017 10:23:41 -0000

Y'all --

The Network Collective has a twice a month videocast on the history of =
network engineering (which could be protocols, organizations, or =
whatever --). I didn't post this when it happened, and I should have, =
but Juliusz was on to talk about the history of BABEL. The recording is =
here --

http://thenetworkcollective.com/2017/08/hon-babel/

The entire list of episodes is here --

http://thenetworkcollective.com/category/episodes/history-of-networking/

=F0=9F=98=8A

Russ


From nobody Thu Nov 16 06:35:31 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC40127137; Thu, 16 Nov 2017 06:35:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmpECVEr3WSG; Thu, 16 Nov 2017 06:35:06 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160F112950B; Thu, 16 Nov 2017 06:35:05 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAGEZ37H017190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Nov 2017 15:35:03 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vAGEZ3pH021938; Thu, 16 Nov 2017 15:35:03 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 81578EB364; Thu, 16 Nov 2017 15:35:03 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id m3rSXXWDnV6c; Thu, 16 Nov 2017 15:34:59 +0100 (CET)
Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 76B89EB216; Thu, 16 Nov 2017 15:34:59 +0100 (CET)
Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1eFLFr-0003rD-4p; Thu, 16 Nov 2017 15:34:59 +0100
Date: Thu, 16 Nov 2017 15:34:59 +0100
Message-ID: <7ir2sy47ho.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: "homenet@ietf.org" , babel@ietf.org
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 16 Nov 2017 15:35:03 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 16 Nov 2017 15:35:03 +0100 (CET)
X-Miltered: at korolev with ID 5A0DA217.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5A0DA217.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A0DA217.003 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5A0DA217.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 : 5A0DA217.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5A0DA217.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: [babel] About draft-homenet-babel-profile
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 16 Nov 2017 14:35:11 -0000

Cross-posting between Babel and Homenet.

At this morning's Babel meeting, Barbara asked whether the work going on
in Babel on security means that homenet-babel-profile should be delayed.

I said no.  Please, no.  I beg you, Barbara, no.

I started working on this document in early autumn of 2016.  I've done
a lot of work on it, listened to a fair amount of feedback, and it's
reached a state where it's concise, accurate and understandable.

After over a year, my enthusiasm for this document is starting to wane.
I now still have enough energy to go through IESG review, I cannot promise
that it'll still be the case if it is delayed by a few months, or,
Eris forbid, years.

Let's please advance this document, and use the energy we'll save this way
to improve the security of both Babel and Homenet.

-- Juliusz


From nobody Thu Nov 16 06:44:30 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3C912950B; Thu, 16 Nov 2017 06:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgAoMZzEOOyy; Thu, 16 Nov 2017 06:44:23 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5FF12711B; Thu, 16 Nov 2017 06:44:22 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAGEiKFS022570; Thu, 16 Nov 2017 15:44:20 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B6089EB364; Thu, 16 Nov 2017 15:44:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id MbkvgktYLrxM; Thu, 16 Nov 2017 15:44:19 +0100 (CET)
Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 964FEEB365; Thu, 16 Nov 2017 15:44:19 +0100 (CET)
Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1eFLOt-0003wi-B2; Thu, 16 Nov 2017 15:44:19 +0100
Date: Thu, 16 Nov 2017 15:44:19 +0100
Message-ID: <7imv3m4724.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: babel@ietf.org, bier@ietf.org
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 16 Nov 2017 15:44:20 +0100 (CET)
X-Miltered: at korolev with ID 5A0DA444.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A0DA444.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 : 5A0DA444.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 bierin6 and signalling of encapsulation
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 16 Nov 2017 14:44:25 -0000

Hi,

Crossposted between BIER and Babel.

Thanks a lot to Sandy for presenting bierin6 this morning at the Babel
meeting.  I asked a question about how encapsulation is signalled, and
Tony answered it doesn't matter.  He's probably right, but I need an
explanation.

Suppose a BIER router A has a neighbour B.  From the routing protocol, it
has learnt that frames with a given bit index set are to be forwarded to
B.  How does it know which among the different BIER encapsulations to use
in order to send its BIER frames to B?

I'm probably missing something, but I only see three solutions:

  1. statically configured (e.g. a given BIER domain is statically
     configured to use a given encapsulation);

  2. carried by a specific signalling protocol (call it the BIER Hello
     Protocol for now);

  3. carried by the routing protocol (e.g. carried by a sub-TLV of the IHU
     TLV in Babel, or using RFC 5613 signalling in OSPF).

So what's the vision here?

-- Juliusz


From nobody Thu Nov 16 09:06:50 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0160712969E; Thu, 16 Nov 2017 09:06:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 pFtX3Wl0qOrz; Thu, 16 Nov 2017 09:06:46 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262B9126D73; Thu, 16 Nov 2017 09:06:46 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id z3so1606458wme.3; Thu, 16 Nov 2017 09:06:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wroRKNHagZ4B3ekFKG/LF5KKBoKS6oi/Djh/W98p7/A=; b=Si1fM+PK1qz1ppLK+BS8PE0H+z7gCpq+bHEc3GzmqyRPyqkqWfpUui8tiRXJMZ4mVe hMnv8PIBNKRXzzK6d/xsJHn19Jn0/2Vz7tXp9wd2yM8WMU1Q91XluZAJKXE6kcVQEeGc qgTJOHbY4z7jWn9NKWE9iC5wFyUH+l+4xmKVEpEvR8sGg59Bn6Jf3IXvST88FL0HeXkZ tEph0mfHHIZb1YZ4PEIj0sFio7lH0itMNBetOyZB4Pvx2LRSPCWnBskOKRoVUMy+uln2 sEXeYEzpXjHjWBfhZTqaCM4kyPkWLkYTcz1aBWns7xtt945hfy9n+BgDZD/axtRM+30H IFPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wroRKNHagZ4B3ekFKG/LF5KKBoKS6oi/Djh/W98p7/A=; b=qwTg972nAqSPKWrKCZnSF7UKNCrIOXlZYYTAtfvmApK7DA6a4j+ltWB1LIWQULEtXb WhyPPHd+D7+gUpp5c2gYke3hraruhzc6NMWqyj1dgpa3CKYDP81ZCJEE9o2Z4OnkhsY7 9BpCpiTj9JxwNKtroeN4DXh6tS9C+2PT18B4whhtkdKcqaGW9p5Ja+zEBkwf2K9e9VXa NX7UA6v9ysNMGoXZJSUS0oANll1EZpuRoIVjvALFMGzW5kgjDyhmAMDvMFA9+IQAOXW8 Vp7P0grKmt/GfAUoYoUdWSERQiTQ8i0xoFjRuzgEbF6hYvfyA6+MCoZJaWJUeSO5wzBA k6sw==
X-Gm-Message-State: AJaThX5zgkB3imQQcRmfJWXAMCql1ddgAU1XzY0BGSFk8FQvLlSC2S+P dPiVR7U4DIsLWp6qncTqTjQ3LBPVi5PXINcbNgHGOg==
X-Google-Smtp-Source: AGs4zMawHPeTeb37dmZORC31xuXmBaYY/b2R3aP5Q7F9tvrMGr0WiI584nl7yju8YT40ifgL0PorUkhUH4FznjiF6/0=
X-Received: by 10.80.245.181 with SMTP id u50mr3641761edm.171.1510852004707; Thu, 16 Nov 2017 09:06:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.164.199 with HTTP; Thu, 16 Nov 2017 09:06:04 -0800 (PST)
In-Reply-To: <7imv3m4724.wl-jch@irif.fr>
References: <7imv3m4724.wl-jch@irif.fr>
From: Tony Przygienda 
Date: Fri, 17 Nov 2017 01:06:04 +0800
Message-ID: 
To: Juliusz Chroboczek 
Cc: Babel at IETF , "bier@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114e64800c81a4055e1ca5c9"
Archived-At: 
Subject: Re: [babel] [Bier] About bierin6 and signalling of encapsulation
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 16 Nov 2017 17:06:48 -0000

--001a114e64800c81a4055e1ca5c9
Content-Type: text/plain; charset="UTF-8"

you simply pick either one, it's a hop-by-hop decision. Sufficient. That
way we can simply run BIERin6 first and then add the ether cap TLV and
start to remove the BIERin6 encaps TLVs (given SD,SI,BML are same) ...

--- tony



On Thu, Nov 16, 2017 at 10:44 PM, Juliusz Chroboczek  wrote:

> Hi,
>
> Crossposted between BIER and Babel.
>
> Thanks a lot to Sandy for presenting bierin6 this morning at the Babel
> meeting.  I asked a question about how encapsulation is signalled, and
> Tony answered it doesn't matter.  He's probably right, but I need an
> explanation.
>
> Suppose a BIER router A has a neighbour B.  From the routing protocol, it
> has learnt that frames with a given bit index set are to be forwarded to
> B.  How does it know which among the different BIER encapsulations to use
> in order to send its BIER frames to B?
>
> I'm probably missing something, but I only see three solutions:
>
>   1. statically configured (e.g. a given BIER domain is statically
>      configured to use a given encapsulation);
>
>   2. carried by a specific signalling protocol (call it the BIER Hello
>      Protocol for now);
>
>   3. carried by the routing protocol (e.g. carried by a sub-TLV of the IHU
>      TLV in Babel, or using RFC 5613 signalling in OSPF).
>
> So what's the vision here?
>
> -- Juliusz
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>

--001a114e64800c81a4055e1ca5c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


you simply pick either one, it's a hop-by-hop decision=
. Sufficient. That way we can simply run BIERin6 first and then add the eth=
er cap TLV and start to remove the BIERin6 encaps TLVs (given SD,SI,BML are=
 same) ...=C2=A0

--- tony=C2=A0



<=
div class=3D"gmail_quote">On Thu, Nov 16, 2017 at 10:44 PM, Juliusz Chroboc=
zek <=
jch@irif.fr> wrote:
Hi,



Crossposted between BIER and Babel.



Thanks a lot to Sandy for presenting bierin6 this morning at the Babel

meeting.=C2=A0 I asked a question about how encapsulation is signalled, and=


Tony answered it doesn't matter.=C2=A0 He's probably right, but I n=
eed an

explanation.



Suppose a BIER router A has a neighbour B.=C2=A0 From the routing protocol,=
 it

has learnt that frames with a given bit index set are to be forwarded to
B.=C2=A0 How does it know which among the different BIER encapsulations to =
use

in order to send its BIER frames to B?



I'm probably missing something, but I only see three solutions:



=C2=A0 1. statically configured (e.g. a given BIER domain is statically

=C2=A0 =C2=A0 =C2=A0configured to use a given encapsulation);



=C2=A0 2. carried by a specific signalling protocol (call it the BIER Hello=


=C2=A0 =C2=A0 =C2=A0Protocol for now);



=C2=A0 3. carried by the routing protocol (e.g. carried by a sub-TLV of the=
 IHU

=C2=A0 =C2=A0 =C2=A0TLV in Babel, or using RFC 5613 signalling in OSPF).


So what's the vision here?



-- Juliusz



_______________________________________________

BIER mailing list

BIER@ietf.org

https://www.ietf.org/mailman/listinfo/bier





--001a114e64800c81a4055e1ca5c9--


From nobody Thu Nov 16 09:16:55 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA4C124D6C; Thu, 16 Nov 2017 09:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0G1p3SKn8Hj; Thu, 16 Nov 2017 09:16:52 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB71124D37; Thu, 16 Nov 2017 09:16:51 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAGHGofg011066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Nov 2017 18:16:50 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vAGHGoKP025841; Thu, 16 Nov 2017 18:16:50 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 37DFDEB367; Thu, 16 Nov 2017 18:16:50 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id pAYDXHG1Umrm; Thu, 16 Nov 2017 18:16:49 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 56240EB365; Thu, 16 Nov 2017 18:16:49 +0100 (CET)
Date: Thu, 16 Nov 2017 18:16:49 +0100
Message-ID: <874lpum9dq.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: Tony Przygienda 
Cc: Babel at IETF , "bier@ietf.org" 
In-Reply-To: 
References: <7imv3m4724.wl-jch@irif.fr> 
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 16 Nov 2017 18:16:50 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 16 Nov 2017 18:16:50 +0100 (CET)
X-Miltered: at korolev with ID 5A0DC802.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5A0DC802.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A0DC802.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5A0DC802.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 : 5A0DC802.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5A0DC802.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] [Bier] About bierin6 and signalling of encapsulation
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 16 Nov 2017 17:16:54 -0000

> you simply pick either one, it's a hop-by-hop decision.

What if A implements both encapsulations, and B only implements bierin6?
If A picks the native encapsulation, you've created a blackhole, no?

-- Juliusz


From nobody Thu Nov 16 18:31:22 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7F4124D68; Thu, 16 Nov 2017 18:31:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.124
X-Spam-Level: 
X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 KGUCAN6vxwPk; Thu, 16 Nov 2017 18:31:12 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-oln040092005080.outbound.protection.outlook.com [40.92.5.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688ED12008A; Thu, 16 Nov 2017 18:31:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qs3NBe80aA3i31UETxkI4Bw3vokDYuD+ewIfadWpp/A=; b=Vf/t0G4nqSKXVZpl0jXdWFBQYLW40J3fo3sRsYFLP4GtgXtLcPvrxSwUlKt6S0/1UggIzKnh1ab5vdsADrbXUM23PaV/7sm1Uvi+MWxj4HYpUAGFHmqWZU0eG0VoMh+Ral/5HGkfj2yNXFvzg1peg5Mv+VUZWZrLbw4Tw7krmpO7U151DHK8/yQt4t/m2u1kmznS3XrOiednWmu6nkbt6TIb2FRnXiij655f+juhYpTU0pF1wa5X1gWaaMZe0zOfTY+zsyj8ztkGpi6nRt4yeyJLvUPmNuQMzZ0UmDq6Odl1j7VSbXlMAWSK665k82XhZSfFgscv2SvSgHOXVwG7VQ==
Received: from BL2NAM02FT042.eop-nam02.prod.protection.outlook.com (10.152.76.58) by BL2NAM02HT040.eop-nam02.prod.protection.outlook.com (10.152.77.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12; Fri, 17 Nov 2017 02:31:11 +0000
Received: from CY1PR07MB2634.namprd07.prod.outlook.com (10.152.76.56) by BL2NAM02FT042.mail.protection.outlook.com (10.152.76.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.218.12 via Frontend Transport; Fri, 17 Nov 2017 02:31:11 +0000
Received: from CY1PR07MB2634.namprd07.prod.outlook.com ([10.167.16.148]) by CY1PR07MB2634.namprd07.prod.outlook.com ([10.167.16.148]) with mapi id 15.20.0218.015; Fri, 17 Nov 2017 02:31:10 +0000
From: Zhang Z 
To: Juliusz Chroboczek , Tony Przygienda 
CC: "bier@ietf.org" , Babel at IETF 
Thread-Topic: [babel] [Bier] About bierin6 and signalling of encapsulation
Thread-Index: AQHTXv1Mbd2zqpO9Xk6Ysp4M7DcV36MXP2WAgACW1k4=
Date: Fri, 17 Nov 2017 02:31:10 +0000
Message-ID: 
References: <7imv3m4724.wl-jch@irif.fr> , <874lpum9dq.wl-jch@irif.fr>
In-Reply-To: <874lpum9dq.wl-jch@irif.fr>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: irif.fr; dkim=none (message not signed) header.d=none;irif.fr; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:6EBFA86B70D2A1BEB5E73E9905EFC551B9E9C2453154E02E8132E384FF754174; UpperCasedChecksum:BED146AB122768C7C6F3F6452293832C9527E297C0F6DB1C25FC82929D951A73; SizeAsReceived:7275; Count:46
x-tmn: [nbP529tXbf4pkYE+2+MvErN6EQdt39n6fU1hKU0EXF0y6VCm/tHdtjtzPybfwIwz]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL2NAM02HT040; 6:EC3wpwC5gXl8nFlEbwdWZqHYDd9O20IZHeJVeiuD9X/FOfhdmtX6hqdlwvKJ4zDL4r5DGpKYDGcqICPN8zWWEHiOAZ3bcKgM5M7H1zmj7HhkDzvvOYKeoNW3vzOfQLcpf7ni7vhp14jIzmRQojtKnG+YfjqhklCn0miCkgnX7fVLqr/C2tvIdd9I6qIT+n6fP3fAs92OpJPXYyfGvKoRp1ayBhv88+yI38CqCHngQjq5EcM4ZvgysihllbhNF2ikSmzt1PUp35sjOyVGaoQD/gDlfouxq2exFTngY5Mx3mL2wvLqwKnVraNCbkVoefAAFs6080PNYllOVoz2NPw0Leji4/gVtr6pEPGZLnUuegg=; 5:0hxfvQaPacV9qIbjEoJcSS1WVn/6WLql+olQ3YTvdCND3hfjtAP6BGFOODnHj/ijPS4VDD52jW0aRWkmtjApARMbpDfF7achq35cZjGo/UlbeK3Ujmy0M2Mt4LqYBYiiknHtTgdnlMKik1WNx0We9rjQU2GrDnzCo72bKZp18kI=; 24:FqSBszttzeato1p8eNlkGLBjW3Rdhwro+2pyJIk8/qr6ETUohPHYoo87e5mwLU3uZaU2FuzV4UEEMtREb38fqe6Ur8i2sBsPPCULKp1MYbk=; 7:Vdc8fyql91gzDBVexVcMu8vu8jwQh9gTIkcOWaLvW3JAHvp8YQqZEXOq2tZ7tNEHUm381a9LDUbYA9KX+jozzDzpTHgZyEFUUMNgSPv9q/CPgtTA66WnDNXB0Dffol5hyo3B9IgPNTR25EiDkHSNsanrZUbdlQJDvAKovNvKrzltEjNlVBL/sI24LM/2ugbhy3ANw+pBAAlRrqcLJruN7t48QTylCBnzNRIjYX8obht49phyo4M2qlMD3L5yz9mt
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 719528e5-322f-48a4-d49a-08d52d6343bd
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:BL2NAM02HT040; 
x-ms-traffictypediagnostic: BL2NAM02HT040:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:BL2NAM02HT040; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BL2NAM02HT040; 
x-forefront-prvs: 049486C505
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BL2NAM02HT040; H:CY1PR07MB2634.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR07MB263424813C6E420834EB55498E2F0CY1PR07MB2634namp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 719528e5-322f-48a4-d49a-08d52d6343bd
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 02:31:10.1194 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT040
Archived-At: 
Subject: Re: [babel] [Bier] About bierin6 and signalling of encapsulation
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Nov 2017 02:31:14 -0000

--_000_CY1PR07MB263424813C6E420834EB55498E2F0CY1PR07MB2634namp_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgSnVsaXVzeiwNCg0KMS4gc3RhdGljYWxseSBjb25maWd1cmVkIChlLmcuIGEgZ2l2ZW4gQklF
UiBkb21haW4gaXMgc3RhdGljYWxseQ0KICAgICBjb25maWd1cmVkIHRvIHVzZSBhIGdpdmVuIGVu
Y2Fwc3VsYXRpb24pOw0KU2FuZHk6IFllcywgc3RhdGljIGNvbmZpZ3VyYXRpb24gcHJvdmlkZXMg
YSBzaW1wbGUgd2F5IHRvIGltcGxlbWVudCBiaWVyIGZvcndhcmRpbmcuDQoNCiAgMi4gY2Fycmll
ZCBieSBhIHNwZWNpZmljIHNpZ25hbGxpbmcgcHJvdG9jb2wgKGNhbGwgaXQgdGhlIEJJRVIgSGVs
bG8NCiAgICAgUHJvdG9jb2wgZm9yIG5vdyk7DQpTYW5keTogQmllciBub2RlIGluZm9ybWF0aW9u
IGlzIGFkdmVydGlzZWQgYnkgSUdQLyBCR1AgcHJvdG9jb2wgKGFzIHlvdSBtZW50aW9uZWQgIkJp
ZXIgaGVsbG8gcHJvdG9jb2wiKSwgQmlmdC1pZCBpcyB0aGUga2V5IHRvIGZpbmQgdGhlIGNvcnJl
c3BvbmRpbmcgZm9yd2FyZGluZyBpdGVtLiBCdXQgdGhlcmUncyBubyByZXN0cmljdGlvbiBmb3Ig
dGhlIG91dC1sYXllciBlbmNhcHN1bGF0aW9uLiBJbiBmYWN0LCB0aGUgQmllciBwYWNrZXRzIGNh
biBiZSBleGVjdXRlZCBjb3JyZWN0bHkgd2hhdGV2ZXIgdGhlIG91dC1sYXllciBpcywgc3VjaCBh
cyBNcGxzLCBFdGhlcm5ldCBvciBJUHY2LCBhbmQgc28gb24uIFRoZSBvdXQtbGF5ZXIgZW5jYXBz
dWxhdGlvbiBpcyBvbmx5IHVzZWQgdG8gbWFrZSBzdXJlIHRoZSBCaWVyIHBhY2tldCBjYW4gYmUg
cmVjZWl2ZWQgY29ycmVjdGx5IGJ5IHRoZSBuZXh0IGhvcCByb3V0ZXIuDQpUbyB5b3VyIGV4YW1w
bGUsIEEgc2VuZHMgdGhlIGJpZXIgcGFja2V0IHdpdGggd2hhdGV2ZXIgZW5jYXBzdWxhdGlvbiwg
aW5kZWVkIHRoZSBwYWNrZXQgd2lsbCBiZSByZWNlaXZlZCBhbmQgZXhlY3V0ZWQgY29ycmVjdGx5
IGJ5IEIuIEEgc2hvdWxkIGNob29zZSBhIHJlYXNvbmFibGUgZW5jYXBzdWxhdGlvbiBtZXRob2Qg
dGhvdWdoIGl0IGNhbiBjaG9vc2UgdGhlIG1ldGhvZCBvcHRpb25hbGx5LiBJbiBmYWN0IHRoZXJl
J3MgY29uc2Vuc3VzIGluIG9uZSBiaWVyIGRvbWFpbi4NCg0KICAzLiBjYXJyaWVkIGJ5IHRoZSBy
b3V0aW5nIHByb3RvY29sIChlLmcuIGNhcnJpZWQgYnkgYSBzdWItVExWIG9mIHRoZSBJSFUNCiAg
ICAgVExWIGluIEJhYmVsLCBvciB1c2luZyBSRkMgNTYxMyBzaWduYWxsaW5nIGluIE9TUEYpLg0K
U2FuZHk6IFlvdSBuZWVkbid0IGRvIHRoYXQuIEJ1dCB5b3UgY2FuIHRyeSBpZiB5b3UgaW5zaXN0
IG9uIGl0Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogYmFiZWwg
PGJhYmVsLWJvdW5jZXNAaWV0Zi5vcmc+ILT6se0gSnVsaXVzeiBDaHJvYm9jemVrIDxqY2hAaXJp
Zi5mcj4NCreiy83KsbzkOiAyMDE3xOoxMdTCMTfI1SAxOjE2OjQ5DQrK1bz+yMs6IFRvbnkgUHJ6
eWdpZW5kYQ0Ks63LzTogYmllckBpZXRmLm9yZzsgQmFiZWwgYXQgSUVURg0K1vfM4jogUmU6IFti
YWJlbF0gW0JpZXJdIEFib3V0IGJpZXJpbjYgYW5kIHNpZ25hbGxpbmcgb2YgZW5jYXBzdWxhdGlv
bg0KDQo+IHlvdSBzaW1wbHkgcGljayBlaXRoZXIgb25lLCBpdCdzIGEgaG9wLWJ5LWhvcCBkZWNp
c2lvbi4NCg0KV2hhdCBpZiBBIGltcGxlbWVudHMgYm90aCBlbmNhcHN1bGF0aW9ucywgYW5kIEIg
b25seSBpbXBsZW1lbnRzIGJpZXJpbjY/DQpJZiBBIHBpY2tzIHRoZSBuYXRpdmUgZW5jYXBzdWxh
dGlvbiwgeW91J3ZlIGNyZWF0ZWQgYSBibGFja2hvbGUsIG5vPw0KDQotLSBKdWxpdXN6DQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpiYWJlbCBtYWls
aW5nIGxpc3QNCmJhYmVsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2JhYmVsDQo=

--_000_CY1PR07MB263424813C6E420834EB55498E2F0CY1PR07MB2634namp_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable






Hi Juliusz,



1. statically configured (e.g. a given BIER domain is statically

     configured to use a given encapsulation);

Sandy: Yes, static configuration provides a simple way to implement bier fo=
rwarding.




  2. carried by a specific signalling protocol (call it the BIER Hello=


     Protocol for now);

Sandy: Bier node information is advertised by IGP/ BGP protocol (as you men=
tioned "Bier hello protocol"), Bift-id is the key to find the cor=
responding forwarding item. But there's no restriction for the out-layer en=
capsulation. In fact, the Bier packets can
 be executed correctly whatever the out-layer is, such as Mpls, Ethernet or=
 IPv6, and so on. The out-layer encapsulation is only used to make sure the=
 Bier packet can be received correctly by the next hop router.

To your example, A sends the bier packet with whatever encapsulation, indee=
d the packet will be received and executed correctly by B. A should choose =
a reasonable encapsulation method though it can choose the method optionall=
y. In fact there's consensus in
 one bier domain.



  3. carried by the routing protocol (e.g. carried by a sub-TLV of the=
 IHU

     TLV in Babel, or using RFC 5613 signalling in OSPF).
Sandy: You needn't do that. But you can try if you insist on it.




=B7=A2=BC=FE=C8=CB: babel &=
lt;babel-bounces@ietf.org> =B4=FA=B1=ED Juliusz Chroboczek <jch@irif.=
fr>

=B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA11=D4=C217=C8=D5 1:16:49

=CA=D5=BC=FE=C8=CB: Tony Przygienda

=B3=AD=CB=CD: bier@ietf.org; Babel at IETF

=D6=F7=CC=E2: Re: [babel] [Bier] About bierin6 and signalling of enc=
apsulation

 






> you simply pick either one, it's a hop-by-hop=
 decision.



What if A implements both encapsulations, and B only implements bierin6?
If A picks the native encapsulation, you've created a blackhole, no?



-- Juliusz



_______________________________________________

babel mailing list

babel@ietf.org

https://www.ietf.or=
g/mailman/listinfo/babel








--_000_CY1PR07MB263424813C6E420834EB55498E2F0CY1PR07MB2634namp_--


From nobody Fri Nov 17 02:34:37 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06305128D86; Fri, 17 Nov 2017 02:34:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level: 
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRzEZ56DirOR; Fri, 17 Nov 2017 02:34:29 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C5B1279EB; Fri, 17 Nov 2017 02:34:28 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAHAYPBu019512; Fri, 17 Nov 2017 11:34:25 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 421D9EB364; Fri, 17 Nov 2017 11:34:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id X57X1URNmqAP; Fri, 17 Nov 2017 11:34:24 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 64410EB367; Fri, 17 Nov 2017 11:34:23 +0100 (CET)
Date: Fri, 17 Nov 2017 11:34:23 +0100
Message-ID: <87zi7lp51s.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: Zhang Z 
Cc: Tony Przygienda , "bier@ietf.org" , Babel at IETF 
In-Reply-To: 
References: <7imv3m4724.wl-jch@irif.fr> 
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 17 Nov 2017 11:34:25 +0100 (CET)
X-Miltered: at korolev with ID 5A0EBB31.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A0EBB31.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 : 5A0EBB31.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] [Bier] About bierin6 and signalling of encapsulation
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Nov 2017 10:34:31 -0000

> In fact there's consensus in one bier domain.

I'm not sure I'm happy with that.  For one, it means that you cannot
migrate a domain incrementally.

-- Juliusz


From nobody Fri Nov 17 07:34:25 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52381273B1; Fri, 17 Nov 2017 07:34:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HJ5JyVY3VdP9; Fri, 17 Nov 2017 07:34:16 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F408D127735; Fri, 17 Nov 2017 07:34:02 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id z3so7230145wme.5; Fri, 17 Nov 2017 07:34:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CsQ/mLWbFaEq2TaKpKDBJXLpjMFAxR79IrCu7yhodVk=; b=hS5U0X8MRl25qGwFTe5RUkbRAOnw9UCu/8/vDyt4kpITkYabhK6fm9LvKu57T3rJqG RjFJxxPyO6R17KOwc1ysyyokVU53wMG+e0ruRIE4SXByF3GifZFB51h+MLsCLBgmKWgD jXvYIfexSYbwm87mwhwAhFrpFwiIvkrz96okhpUaZxYGx2fCOddw9vmiaNU27JkR82p7 J7zMECAGkbNfcjpzn3+A5mFnSGVdB39//bRmcAoZLKl3LkP9i+tUAeKBUtWa8v4I97mf psVPZGoi529oTc4Ok6gX6p3MaTwu3MFQe1QiZBh9nvPrY7CL7lDd3sW8ESm5WRaXv+T5 8W/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CsQ/mLWbFaEq2TaKpKDBJXLpjMFAxR79IrCu7yhodVk=; b=cfOri+FAnkCQOPzTO2ygFvWB8x7Q+DOxgtSXmp8/QcH5smVbzA7naDtUwJxzXcxTwF CMl1kanMnZGd8Fgr/ySARZ++IvPZhMxFCuQr3OaVp/+4dIKkLCKPX/b/hsjkGAnLUNMj g88FKXJm/eynvdfpFvn25wf2PJtjiJLZJiFJ0xCbp5iVSH24hq15oVVuRUVlXdkWNMcU u14xk1sv8garTEKrhrROaTNoGT/1rn+2qGm3R2qAxcKt2eYbMRQOWRB6LVY3H+/LX4Wm 2DWmeifePF7EJqQ7zMEscUwenMts5B4cr7lLn+1K6iOQUy0Ft190wxiXUpOyXVpWNyxl eqzw==
X-Gm-Message-State: AJaThX7XGmM89kdaxV8b9Jnz8X+U1Dr9+tD5/XU0bzSASgswZP3L6sj9 0jNYxCsSPtb+9U0gXZIAYTkSxBb7sIqcVaP4x1o=
X-Google-Smtp-Source: AGs4zMYTj9KkYChacHydaXqoyuueeJfQ+yLhO7Iv25NUxXSGeH7W8NRzm6skQPf/uxeNxj73Ut8PWbvCUwadl/CGP7U=
X-Received: by 10.80.226.74 with SMTP id o10mr8047135edl.290.1510932841568; Fri, 17 Nov 2017 07:34:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.164.199 with HTTP; Fri, 17 Nov 2017 07:33:19 -0800 (PST)
In-Reply-To: <87zi7lp51s.wl-jch@irif.fr>
References: <7imv3m4724.wl-jch@irif.fr>   <87zi7lp51s.wl-jch@irif.fr>
From: Tony Przygienda 
Date: Fri, 17 Nov 2017 23:33:19 +0800
Message-ID: 
To: Juliusz Chroboczek 
Cc: Zhang Z , "bier@ietf.org" ,  Babel at IETF 
Content-Type: multipart/alternative; boundary="f403043e165c4d1d87055e2f77c1"
Archived-At: 
Subject: Re: [babel] [Bier] About bierin6 and signalling of encapsulation
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 17 Nov 2017 15:34:19 -0000

--f403043e165c4d1d87055e2f77c1
Content-Type: text/plain; charset="UTF-8"

either encapsulation can be picked and with that migration is trivial ...

Again, architecture doesn't spell that out but if SD/SI/BML match you can
use any encaps to reach the neighbor


--- tony

On Fri, Nov 17, 2017 at 6:34 PM, Juliusz Chroboczek  wrote:

> > In fact there's consensus in one bier domain.
>
> I'm not sure I'm happy with that.  For one, it means that you cannot
> migrate a domain incrementally.
>
> -- Juliusz
>

--f403043e165c4d1d87055e2f77c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


either encapsulation can be picked and with that migration=
 is trivial ...=C2=A0

Again, architecture doesn't sp=
ell that out but if SD/SI/BML match you can use any encaps to reach the nei=
ghbor


--- tony=C2=A0

On Fri, Nov 17, 2017=
 at 6:34 PM, Juliusz Chroboczek <jch@irif.fr> wrote:
> In fact there's consensus in=
 one bier domain.



I'm not sure I'm happy with that.=C2=A0 For one, it means th=
at you cannot

migrate a domain incrementally.



-- Juliusz





--f403043e165c4d1d87055e2f77c1--


From nobody Sun Nov 19 07:28:08 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA8C126DED for ; Sun, 19 Nov 2017 07:28:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az7PglAqJZWG for ; Sun, 19 Nov 2017 07:28:06 -0800 (PST)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42AF61243FE for ; Sun, 19 Nov 2017 07:28:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1511105279;  s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=325; bh=jyTEeWEvpb6EuH9bNebQF39RbpLnvt/2+TZ1HCwVa80=; b=ljgq4Yc6bwPDcP0knqZdetduenpG70wQlm9RYXwxRnHhXvGj9L6ox/BpObCia5uD j8rgXgY6Tlx7jtZ5jwWNxLkHsEp2J7P1WHG1v1W7IIkGJE1vcwviOxUZ40gFmLGROKQ RcgtfbC/a7pdOB9eQ0tTMi9uClJwLkoaT3BbbnnE=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1511105279184867.641233148354; Sun, 19 Nov 2017 07:27:59 -0800 (PST)
Date: Sun, 19 Nov 2017 15:27:59 +0000
From: Denis Ovsienko 
To: "Babel at IETF" 
Message-ID: <15fd4e4b4ce.12b2a038240474.5575299947607345982@ovsienko.info>
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: 
Subject: [babel] draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 19 Nov 2017 15:28:07 -0000

Hello list.

Here is a couple editorial suggestions for the source-specific I-D:

* In the abstract: there is no such thing as Experimental Track, it is just Experimental.
* In Section 7.1: it may be useful to note that in a well-formed Source Prefix sub-TLV the value of Length is at least 2.

-- 

    Denis Ovsienko





From nobody Mon Nov 20 07:48:00 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6E0129B26; Mon, 20 Nov 2017 07:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSYK0PfwV4Y4; Mon, 20 Nov 2017 07:47:56 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9CE129B17; Mon, 20 Nov 2017 07:47:42 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAKFkvtn031518; Mon, 20 Nov 2017 07:47:39 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=PPS1017; bh=K/ddTXgfX3auelf8SQxC9+SBu5UmdIF1puJ4CXyF5ow=; b=FgicJCeUsG/PLdurZIDDIMWhCtw4e2gmwhHjWxmF+hgj6crAoHDVvRqp4jJnP3brFKEL ek3Pq0cEIGz6zVLzs3g6tPHjbLfeDJQQewGhVt6abd8AazyMJ1iD2fXbsMLYJUkoYbOb nCYBIRaFbwGFaUEBuJmQ+47S3CVDChDcEFg2GvA0Z1bisIWz30N68YMdUGtA+xZThrh5 yD0Gv+LrkZbLl7ZmYpCNb86VZ28AEKNDEcPXl+7GF4iLvgilz28vWrlP/pz29Bn8wI/K Vac/VwGEIvW5y6JN4ph413CSPp12mA3iaqo+48shdW+f3k9P4XaxM9ySmQvErjYY5naC uQ== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0085.outbound.protection.outlook.com [207.46.163.85]) by mx0a-00273201.pphosted.com with ESMTP id 2ec0k5r6vj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 20 Nov 2017 07:47:39 -0800
Received: from [172.29.32.239] (66.129.241.12) by SN1PR05MB2302.namprd05.prod.outlook.com (10.169.125.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Mon, 20 Nov 2017 15:47:36 +0000
To: Juliusz Chroboczek , Zhang Z 
Cc: "bier@ietf.org" , Babel at IETF 
References: <7imv3m4724.wl-jch@irif.fr>  <87zi7lp51s.wl-jch@irif.fr>
From: Eric C Rosen 
Message-ID: 
Date: Mon, 20 Nov 2017 10:47:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <87zi7lp51s.wl-jch@irif.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: BN6PR03CA0016.namprd03.prod.outlook.com (10.168.230.154) To SN1PR05MB2302.namprd05.prod.outlook.com (10.169.125.16)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 2d23a253-4309-4ea3-65ab-08d5302e05d8
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:SN1PR05MB2302; 
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2302; 3:SkglOvnb4gGquFHAoVd+aayl04N7uOgOjayXeUMzWVcmHwV7E82VnI1nXCOJqCUZ1yGGCL1fArMiVdfW2jh6Km7LeAoegXeq+HiMoavFtPRj3hotYAVp7SrEIUsF0WYR/HFPdu2oSBR4dr9b8s0cgSUaU7rEyBeGJEyaVG0aQDfH4SH8KWoB7d56ypF8dB7A57ofxzGYOFFd7Axsib+DmthuiOybGAhxWTbx0QuBIM3NWm1Jv5t2YBkUfvO4Po1D; 25:yGYuecKfUmAjwLE8MF5ZtDAlBx+BnkKtqNSyeQo69Mg9LiVVU1jI1Km9VAgya8SOMOHR0BkfHV9IkHpiKBwN/Hbgg1ydgay/yTuGx2ov1OmJCZZj3tEdOrX26sMDKGsPC1HeeXdYWhU8SZOzlMsAWDHZpOHQjoevvV4RUVZ98Mh1yLho180dBRjPg+jqvLToj7s40IfSYOiTEWeDtpsR/LJdnMnD2sjFHd19Pobau3opHPfc/rGhL7mQd5X0T7jg5eshMdTZpndd8DaFM2zppTWLDblUxLY32EX0/51r/Ksr+IVOEoAsb72nscx6TpqA8PyGg3rydPPaK+W9vVfspg==; 31:+ZfR5C60MS3To/NroOYnBZWIeoeIemZpz9pCxGU5N0qfwZHY5DYqO/pG6Xa4ngzxNfDKt3T0gg60RyY4ZlgtI7+/74ts2Xh0ms1838pdeaNm/LXFNDh7mQScCKS85CG8v8KM75C10f7gw5IuzvHJjnuTY3RrX/jMy58PmFHHVDQP/jxV6nzedSKTHmh5h2S+tZ8SQHYN/puBO0rZr8DOVR06a3H7lfErF0q6KwxFcvc=
X-MS-TrafficTypeDiagnostic: SN1PR05MB2302:
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2302; 20:P9UZebV7VOemPUg1S29yLlg4ODGSGURj5QMYRNlSA5J0Jk0y5RxeO099pcDhlhIVwjs4anX9FuLyVC9Xw4xXDKSAu0enymOozMOX0afZve37An6Xiv0Vx+eGQEBY5JyqanReGFttMfw/M6aOeNQFNOnOfLJNrv1Lg7jyJLFjo9bv0I2wb+oP+qE8EBBCVEmw0cO88y/a6swO0YPimNpJhO/qoBhsoiTam63EZnWSy1WycFrBy5QM0piasMVi2gLAowJPUWI47amvyFIyruQAq1VGt35eQj7Y1DxiH5lHqS7AmhgQa5HUXuqjCTUkJgJ/QkGaWzYGLOTOTHy88pm4Cub+VXowv77emzU41KKt935WfdjUhGJV4N4+rsk73wg5loahuiiX34SgXKzW4E1kWKQegxuz9yTOErf3t/zWB0AfXMaV+PPDLyOfICywApPNJIPgeGz4u4RvqP+yXpG7TW3lmVMud6+Q27yKRgRhy64fdVieQu3yPEDcDfLKaNM/U1yOZppwT1Dq26iy17wZ0VZZskdaeBaaLc1UcPbM8J2/Tsq8rzPjreH4mOyFHVHT6ppu3omkGTwPfAlWLVUnCp/V5NWbF+miZFy+j1nZiIw=; 4:KzG/N/f1P4SPcxumot5ZOPF8GF5UsRUFW0+bF2VyaHvu18tUdRV8TCTDDVX8yqPyhflNdQVl9ic7Fe1pY9nCUk3dZxxwMjUPBJap7tMthXrJN0ktueeY1klscmgUyRdE4MEhaTNl+vByKiwv2SlMReaUYHC3+duch/jGTGR+CU+qwK8lVJIAE5o3B+TZVInZ5gZ8jmaxi3ocTPIhXzyJAtVrfHnkWRnzpCTfbJJzOtjitJtC5Bsv6zp72wY1tjLpsB41txHmxd6sbfMzqbj9ipGCiXwxcsfP3v6SUcFoh1BixbZ5+SwFjGRRWblpvFBa
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(192374486261705);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(10201501046)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR05MB2302; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR05MB2302; 
X-Forefront-PRVS: 04976078F0
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(39860400002)(346002)(376002)(189002)(199003)(58126008)(68736007)(8936002)(67846002)(23676003)(64126003)(83506002)(39060400002)(5660300001)(65826007)(101416001)(53936002)(4326008)(2906002)(31686004)(6246003)(305945005)(7736002)(229853002)(8676002)(81156014)(81166006)(36756003)(2870700001)(33646002)(106356001)(105586002)(86362001)(90366009)(6486002)(31696002)(77096006)(50466002)(189998001)(2950100002)(3846002)(110136005)(47776003)(6116002)(6666003)(65956001)(65806001)(66066001)(76176999)(54356999)(3260700006)(50986999)(54906003)(97736004)(16526018)(16576012)(25786009)(478600001)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2302; H:[172.29.32.239]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1TUIyMzAyOzIzOjlMVTFsVGVQM2s4eTRIZVJjTEE1aUhpVDVu?= =?utf-8?B?b0JWQU0rYmVDL3hpVmVEeWwrL2o0NkhCeUVDdXBlUHZkakRUSjVnbWxHbFNN?= =?utf-8?B?NFIzd2xZSHpySStFTVlYMnh5T2NBK3BCaG5CZVpzNnBzWVhKOXY4ZCtIVkhX?= =?utf-8?B?cm52ZGRkOEdhb3hEWVJWdUI5NEEwMStZK3V1RXZoWmkrcTV3aG5DWTFkTFVm?= =?utf-8?B?Q0N5cU1VWW1YVlJRN1BzRk8wZlVyUG1TWHA2ZFprSDFGQVZHZmlQQk0rbWlp?= =?utf-8?B?L1Y2c0hVL0hvZUZSSmNUcHFxOVVzZzRreCt0YUJLMkZMVk8vQmhlKzZCcS96?= =?utf-8?B?ZjNnNVowdmNJYmoxdXZORG9ZMFBGMis4UExtQTR5VU1EK0lxb05OL1JBcnY1?= =?utf-8?B?ejZOcVRtaG45Ykx4SjMrTVVFK0dvNjJsUWo3M29RTzNDUlIwdlJhclVqNW1P?= =?utf-8?B?a1VOQ2xRbVRyN0duUEV0bC9BYnlnVlltQWgrR2lDaFd1UUNnQTJzT0tiZko4?= =?utf-8?B?Y2JTMVJFVW5hd3FiVkdOaENqaXNBb2o4SmtMYnlWVkcxY1Y4UEpkdEdlWUg4?= =?utf-8?B?eFhRaVdRdDhuQldjdWEwRDVDK2dwNHJkZU9wUU1zMEx2V0pMako2Q2VwQlpZ?= =?utf-8?B?SHR3aWNOeXk3R0R5MkNmMjJ4Ky8wQXRNRStXa0Q5cFJ2em1ReWxwc2RhbFBQ?= =?utf-8?B?TENCNldDckd3VnpFbVdhWTNpdjhZNENQRFhsakhRY2xQOTFmODR5SmZ6UG56?= =?utf-8?B?ekg2NnlaajR3S2kzUjUrMC96RDcydDJXLzVBSzJvZGxuY3BLRHY2MkVrUzkz?= =?utf-8?B?WkVXYzlNcitIREsyaW00ZGtQNFNBUzdaYmFSckNZK0ZsZ2lOOTBsWDRwSUpa?= =?utf-8?B?WGxsbTlRVmdzeGw5bFQrYmZSSFBET0RqNzJtWGdPcUx2YzBGYWhSam42Z2dh?= =?utf-8?B?ZkdoeDUzTEdUSHlIeXRYL0NlQWVUdkVKdmFqeGpaYm1jN3Rvdm9nMFZySnd6?= =?utf-8?B?Nm5FeWFUU2djUXRnU1FUSmlKS2xsSm9zUGJRQzR4bzYzN0dsazhWQ25GT05W?= =?utf-8?B?UEpEc2FFaVNqdGtuYTJVbGgxMmxhQy9PbmlQR1RLYkJXZDF0TCs2SGxxMndJ?= =?utf-8?B?QktUY21Ta2RyOTh3V3RURnNYRi8yTXpNRmxzOXU1amtxVkhoc3FpSWF6YVlz?= =?utf-8?B?M0hhTkxmRktMenFzdVZLY3dHYlVqeTMxdHJ6RHd5WFkxVGt6QktJNHRET1M1?= =?utf-8?B?cTVmekJSL21WeFg1NkJqNHJPT01nYTRpRnpBSk1FbjE3RW5NNGc4azNDQUw2?= =?utf-8?B?STZzWkVnSlExb1VkQndRZ0g4ZjFhVDF6RXVGYXVuR1F1bDhXTDYxcGx6U0hV?= =?utf-8?B?YlhpTFhwc2lHV3pRYkdCeWw3THAzV284d2Q5c2FranJNL3VKZk81ckxjZUZr?= =?utf-8?B?NmlCckNvUENncXJQRmdqczJueTBpR29lYjZ4dlFDeW5BUnBzV0dySTcyR2dG?= =?utf-8?B?V0VMUFBEUzU1RHV1QUlqMWxkbzRMdG5uaVdxbU42R3dUUE5oUk1zdEh1RDJx?= =?utf-8?B?NlMxaE5QRzJSWE9ldHQzZXVTdkpSRkRlT05iUTMzNXJ6NlBFZ2x2dzAyaTFs?= =?utf-8?B?eks2ekpQaUNSSERjaW1QZXpDK3RHRGIrcTBTcDk4bnFEVE5CNHBxZ2dZYzJq?= =?utf-8?B?NGtRNTJyRWV2VTNiVFlrS29XMTU2bS9vRlFNNmpwY2xDd1JJclpaaWVzeER1?= =?utf-8?B?QmpHTTVoQVNHbHRSSjNzbDRjdm5uQTFyTHJ2VHMzWHR0SkUzNXhnM04zUXpj?= =?utf-8?B?ZjFRdi9yOVNzMlpITVFiRGo2Rkd5d29SRlU3NENCeFJtUlIvL28zdjNtdDdQ?= =?utf-8?B?cGd2MG91ZXI1OXhHVjY1NnROVHRaL2lPdjhTRXlaZEM2RnM3N21SOVluZFNM?= =?utf-8?B?MGQxODdCZFVRPT0=?=
X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2302; 6:sQY/QkZJtr//Q0WcPct50wKLoFoIgc5/S2xexqMPnslCepXzXXVTcfDEzjb+fv6K6VnxWS9y0we0/u4bgmzklwnDt5PrImORYLL660+OShfs7c9N4aaF4wtfcbxoBX9fuMeaeq2O+ggm+nXy4xPOARTT8oO/gyhW6FSQBYtG2vbsaRtV+UPaBnX8JDOJYgmM3kFyZv5CBpunJWj/kMsgDWe9vqREjERYtHpIpYLOBZz7yPY68cm90E2iil1YADuxlOkAeNI8HYZn/HLfmMxt6lODOIR8aQmTlQk5JeWRyrYVn03JFiSbH1wfJRV524UDEOC6HbNUeVPtO3kMCPC6hdU5+QAOfIP1e6e6LNod/DY=; 5:S6WwNGcgSLGZPe+eM6l7IHdwmykUkp3/isoAHMxWvYllPfxhUEEnvCf6Ttbr+zrwN+MojAP8BfhWgHpnIWI1Mf6P2Dcv/OB2wkX7g2tudhY2UGDkp1ADXw9GFKIx/0IZYckYLBS2vFOQVUKhFEqarv7SJW/0GoYjja6OmtBCVEA=; 24:OJKMQqpfOrQy6/Oi39AghTnkNNYwrRdD0TMLoJrcfCQ8SfdPrOxHJaW3BEJA2aeHKWSrqBGRs1QkjRloVvfjP477GeCbXFVx3xfeVzTbq54=; 7:vSzYZ9JXBNDXNwrvo4TT7k4Qmq1Fuy9uEiHa2ACQOYagbBogmJLlc1l/YKSVoVWg8eKVJ31O4b0nNzFh1OaiNUt/UyfnQs91GJaXd4rbk2j9h9D2lmDIVs2aeZVQCuTbGc2SgnyWomxzJhttClr5/mBS/04HSdTPzVh9IHqKNPs8dqxtHSE4/T8fAHkpx8QQ5e4YmB6i6hf/h81zW8BfUq2c5uWKcYCJQ6jYpkoZa6k5M8FfqE7JxOPwslUCL3H2
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2017 15:47:36.0927 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d23a253-4309-4ea3-65ab-08d5302e05d8
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2302
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-20_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711200212
Archived-At: 
Subject: Re: [babel] [Bier]  About bierin6 and signalling of encapsulation
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 20 Nov 2017 15:47:58 -0000

I think the model is that a BFR knows by virtue of provisioning what 
encapsulation to use by default when transmitting a BIER packet.  If a 
BFR has certain interfaces that lead, e.g., from an MPLS network to an 
IPv6-only network, those interfaces can be provisioned so that the BFR 
knows to use a specified non-default encapsulation when transmitting a 
BIER packet over those interfaces.

In that model, there is no real need for every BFR to know the set of 
encapsulations that every other BFR can receive.

To transition a backbone from one encapsulation to another, one would 
have to first provision all the BFRs to be able to receive both 
encapsulations.  Then one could change the default transmission 
encapsulation on the BFRs one by one.

This model doesn't really support hop-by-hop changing of the 
encapsulation very well, since there is no signaling of the supported 
encapsulation.  But is there really a practical need to optimize for the 
situation in which every hop uses a different encapsulation than the one 
before?

> Juliusz> I'm probably missing something, but I only see three solutions:
>
>    1. statically configured (e.g. a given BIER domain is statically
>       configured to use a given encapsulation);

As suggested above.

>
>    2. carried by a specific signalling protocol (call it the BIER Hello
>       Protocol for now);

I would avoid this.  Hello protocols always seem like they're going to 
be simple, and then turn up being nightmares.  Note that BIER neighbors 
are not necessarily layer 2  neighbors, and once we start sending Hellos 
that are not link-local, the Hellos are easy to attack and we end up 
with some thorny security issues.  I'd certainly want to avoid creating 
new soft state flooding mechanisms for passing BIER control information, 
as we're supposed to be simplifying things rather than making them more 
complicated.

>
>    3. carried by the routing protocol (e.g. carried by a sub-TLV of the IHU
>       TLV in Babel, or using RFC 5613 signalling in OSPF).

IF there is really a practical need for dynamic signaling of "here is 
the list of BIER encapsulations I can parse", adding that information to 
the existing BIER control signaling mechanisms makes sense.  (It's 
analogous to the distribution of information about the supported 
Disposition BSLs).


From nobody Mon Nov 20 13:08:17 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0502128CD5; Mon, 20 Nov 2017 13:08:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 23WSow4F82Ud; Mon, 20 Nov 2017 13:08:13 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524E1120713; Mon, 20 Nov 2017 13:08:13 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id x63so8753924wmf.4; Mon, 20 Nov 2017 13:08:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UiZX6myJJ0Z6ExR5bBx9izZyxRpAqjzacwDvuNMTIoY=; b=f8ZFG/T7zAl1DvVZGIK7gzBlJxpemcqjZMIdn4ZFp724z7aWIRqZqz0AqyytiMd5bG uNMlihBauabsL+FudxymqwsDK2wg1FTU5R2g08bg7PsuJenzKyP2WShV+foUCVC5v7ri eODTAnb1NDKoNbXhHYx5KEh9ZrmCGFqYYJu3GKsBAv+uWuyBSEKs1tjI0rnekTXHA1XF JKNG2R+v8kLFkn27w1wB3p25BmP/Okl1B7I5Q7jU3EB9RGqVEEHHZgYaPviD9lWHkroO HUzh/PSA4IV1RYEqo0q3qRj1RAFupuFtsmFwGY4m6IOiqljnlEJ66WjnglRGldpBke5X 2BgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UiZX6myJJ0Z6ExR5bBx9izZyxRpAqjzacwDvuNMTIoY=; b=UTr0PPSZadeDJQy7rWG7tymXKprx61GrAc64m39CKpGf+9/WsMw6b+sSI9GtqGw1K0 i7i8/q3x1hmikyb3rriZq1V9S/Adct25jxE+QDFkIbMIOgfW37sv3E5+3iSDV81HJ0tJ pzRk6mpKsrgmbQOIvnOvxjHJXETLxvBSKHA3ico9nMIEbKyir8uy20Hgxg1B+lFw8IZj Nn76vlyfZAiMuyXIHSMXNbQ8keasYSMTibNFMYJhPGagCTc9vDoxGUy8NA+WutdqlHPc a6kY2g0HK+qDramhHliQH/M9ImCKy7QIdxEOoW+py7QOkKtYA55/I2oE0ivFNQehNOoZ GzkQ==
X-Gm-Message-State: AJaThX5P9DDLOI7IbRs8gUdZn5EF6M1oJZyyz0pa9oPqa5kQqA1EVoNW J8hROdBnvcQP5Q7LHwz2vssg+k8yGfh8VUiD/6MGvA==
X-Google-Smtp-Source: AGs4zMa6vrLgx49IEGBH6M5X5marwqeFYlOBtbPeNqvz0GZ6kzZC+VC8ObOXNXvz9EKwIBXO0NRbf55qIIQ5wDNsuqA=
X-Received: by 10.80.206.79 with SMTP id k15mr21553004edj.145.1511212091789; Mon, 20 Nov 2017 13:08:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.164.199 with HTTP; Mon, 20 Nov 2017 13:07:31 -0800 (PST)
In-Reply-To: 
References: <7imv3m4724.wl-jch@irif.fr>  <87zi7lp51s.wl-jch@irif.fr> 
From: Tony Przygienda 
Date: Mon, 20 Nov 2017 13:07:31 -0800
Message-ID: 
To: Eric C Rosen 
Cc: Juliusz Chroboczek , Zhang Z ,  "bier@ietf.org" , Babel at IETF 
Content-Type: multipart/alternative; boundary="94eb2c1af95ae9545a055e707b01"
Archived-At: 
Subject: Re: [babel] [Bier]  About bierin6 and signalling of encapsulation
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 20 Nov 2017 21:08:16 -0000

--94eb2c1af95ae9545a055e707b01
Content-Type: text/plain; charset="UTF-8"

1. If we follow today's downstream assigned IGP signalling, each BFR can
choose whatever they want to the next hop as long they have a binding. They
know what the next router supports from its advertisements.  Observe that
the SD binding is encapsulation neutral (i.e. it can advertise multiple
encapsulations per same SI,BML).
2. If BIER relies on the non-MPLS-hard-coded-global-"label" then yes, we
either provision per next neighbor what are viable encapsulations or need
somehow to advertise those. Given we have to advertise whether a router
supports BIER advertising supported encaps doesn't seem to make much
difference to me.
3. I would also abstain from extending hellos

--- tony

On Mon, Nov 20, 2017 at 7:47 AM, Eric C Rosen  wrote:

> I think the model is that a BFR knows by virtue of provisioning what
> encapsulation to use by default when transmitting a BIER packet.  If a BFR
> has certain interfaces that lead, e.g., from an MPLS network to an
> IPv6-only network, those interfaces can be provisioned so that the BFR
> knows to use a specified non-default encapsulation when transmitting a BIER
> packet over those interfaces.
>
> In that model, there is no real need for every BFR to know the set of
> encapsulations that every other BFR can receive.
>
> To transition a backbone from one encapsulation to another, one would have
> to first provision all the BFRs to be able to receive both encapsulations.
> Then one could change the default transmission encapsulation on the BFRs
> one by one.
>
> This model doesn't really support hop-by-hop changing of the encapsulation
> very well, since there is no signaling of the supported encapsulation.  But
> is there really a practical need to optimize for the situation in which
> every hop uses a different encapsulation than the one before?
>
> Juliusz> I'm probably missing something, but I only see three solutions:
>>
>>    1. statically configured (e.g. a given BIER domain is statically
>>       configured to use a given encapsulation);
>>
>
> As suggested above.
>
>
>>    2. carried by a specific signalling protocol (call it the BIER Hello
>>       Protocol for now);
>>
>
> I would avoid this.  Hello protocols always seem like they're going to be
> simple, and then turn up being nightmares.  Note that BIER neighbors are
> not necessarily layer 2  neighbors, and once we start sending Hellos that
> are not link-local, the Hellos are easy to attack and we end up with some
> thorny security issues.  I'd certainly want to avoid creating new soft
> state flooding mechanisms for passing BIER control information, as we're
> supposed to be simplifying things rather than making them more complicated.
>
>
>>    3. carried by the routing protocol (e.g. carried by a sub-TLV of the
>> IHU
>>       TLV in Babel, or using RFC 5613 signalling in OSPF).
>>
>
> IF there is really a practical need for dynamic signaling of "here is the
> list of BIER encapsulations I can parse", adding that information to the
> existing BIER control signaling mechanisms makes sense.  (It's analogous to
> the distribution of information about the supported Disposition BSLs).
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>

--94eb2c1af95ae9545a055e707b01
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


1. If we follow today's downstream assigned IGP signal=
ling, each BFR can choose whatever they want to the next hop as long they h=
ave a binding. They know what the next router supports from its advertiseme=
nts.=C2=A0 Observe that the SD binding is encapsulation neutral (i.e. it ca=
n advertise multiple encapsulations per same SI,BML).=C2=A0
2. If BIER =
relies on the non-MPLS-hard-coded-global-"label" then yes, we eit=
her provision per next neighbor what are viable encapsulations or need some=
how to advertise those. Given we have to advertise whether a router support=
s BIER advertising supported encaps doesn't seem to make much differenc=
e to me.=C2=A0
3. I would also abstain from extending hellos

--- tony=C2=A0

On Mon, Nov 20, 2017 at 7:47 AM, Eric C Rosen <eros=
en@juniper.net> wrote:
I th=
ink the model is that a BFR knows by virtue of provisioning what encapsulat=
ion to use by default when transmitting a BIER packet.=C2=A0 If a BFR has c=
ertain interfaces that lead, e.g., from an MPLS network to an IPv6-only net=
work, those interfaces can be provisioned so that the BFR knows to use a sp=
ecified non-default encapsulation when transmitting a BIER packet over thos=
e interfaces.



In that model, there is no real need for every BFR to know the set of encap=
sulations that every other BFR can receive.



To transition a backbone from one encapsulation to another, one would have =
to first provision all the BFRs to be able to receive both encapsulations.=
=C2=A0 Then one could change the default transmission encapsulation on the =
BFRs one by one.



This model doesn't really support hop-by-hop changing of the encapsulat=
ion very well, since there is no signaling of the supported encapsulation.=
=C2=A0 But is there really a practical need to optimize for the situation i=
n which every hop uses a different encapsulation than the one before?





Juliusz> I'm probably missing something, but I only see three soluti=
ons:



=C2=A0 =C2=A01. statically configured (e.g. a given BIER domain is statical=
ly

=C2=A0 =C2=A0 =C2=A0 configured to use a given encapsulation);





As suggested above.







=C2=A0 =C2=A02. carried by a specific signalling protocol (call it the BIER=
 Hello

=C2=A0 =C2=A0 =C2=A0 Protocol for now);





I would avoid this.=C2=A0 Hello protocols always seem like they're goin=
g to be simple, and then turn up being nightmares.=C2=A0 Note that BIER nei=
ghbors are not necessarily layer 2=C2=A0 neighbors, and once we start sendi=
ng Hellos that are not link-local, the Hellos are easy to attack and we end=
 up with some thorny security issues.=C2=A0 I'd certainly want to avoid=
 creating new soft state flooding mechanisms for passing BIER control infor=
mation, as we're supposed to be simplifying things rather than making t=
hem more complicated.







=C2=A0 =C2=A03. carried by the routing protocol (e.g. carried by a sub-TLV =
of the IHU

=C2=A0 =C2=A0 =C2=A0 TLV in Babel, or using RFC 5613 signalling in OSPF).




IF there is really a practical need for dynamic signaling of "here is =
the list of BIER encapsulations I can parse", adding that information =
to the existing BIER control signaling mechanisms makes sense.=C2=A0 (It=
9;s analogous to the distribution of information about the supported Dispos=
ition BSLs).




_______________________________________________

BIER mailing list

BIER@ietf.org

https://www.ietf.org/mailman/listinfo/bier





--94eb2c1af95ae9545a055e707b01--


From nobody Tue Nov 21 00:16:51 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66E212773A; Tue, 21 Nov 2017 00:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxqxkaGYcexk; Tue, 21 Nov 2017 00:16:47 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1961293E0; Tue, 21 Nov 2017 00:16:47 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAL8GfDd011541; Tue, 21 Nov 2017 09:16:41 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3C547EB217; Tue, 21 Nov 2017 09:16:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 6dVSJjskP84K; Tue, 21 Nov 2017 09:16:39 +0100 (CET)
Received: from mac-matthieu.lan (AAubervilliers-652-1-169-162.w86-218.abo.wanadoo.fr [86.218.8.162]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A87FAEB216; Tue, 21 Nov 2017 09:16:37 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Matthieu Boutier 
In-Reply-To: 
Date: Tue, 21 Nov 2017 09:16:36 +0100
Cc: David Schinazi , rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , babel@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com> <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr> 
To: "Joel M. Halpern" 
X-Mailer: Apple Mail (2.3445.4.7)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 21 Nov 2017 09:16:42 +0100 (CET)
X-Miltered: at korolev with ID 5A13E0E9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A13E0E9.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 : 5A13E0E9.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] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 08:16:50 -0000

> Being a little bit picky here:

All improvements are welcome!  Thanks for the advices and explanations.

> Could you also add a sentence in section 7.1 stating explicitly that =
only one source specific prefix is permitted in a TLV?

I also rewrite the introduction of 7 to precise the behaviour when =
multiple or malformed sub-TLV are received.

Thanks for the feedback.  This is pushed on the git =
(https://github.com/jech/babel-drafts).

Matthieu=


From nobody Tue Nov 21 00:17:01 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCD4129401 for ; Tue, 21 Nov 2017 00:16:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7L5PFvzzJwo for ; Tue, 21 Nov 2017 00:16:55 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2922C126B7E for ; Tue, 21 Nov 2017 00:16:55 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAL8GrwE011646; Tue, 21 Nov 2017 09:16:53 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 84D62EB368; Tue, 21 Nov 2017 09:16:53 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 1SWgdAilDz_G; Tue, 21 Nov 2017 09:16:48 +0100 (CET)
Received: from mac-matthieu.lan (AAubervilliers-652-1-169-162.w86-218.abo.wanadoo.fr [86.218.8.162]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 50045EB21F; Tue, 21 Nov 2017 09:16:48 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Matthieu Boutier 
X-Priority: Medium
In-Reply-To: <15fd4e4b4ce.12b2a038240474.5575299947607345982@ovsienko.info>
Date: Tue, 21 Nov 2017 09:16:47 +0100
Cc: Babel at IETF 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <15fd4e4b4ce.12b2a038240474.5575299947607345982@ovsienko.info>
To: Denis Ovsienko 
X-Mailer: Apple Mail (2.3445.4.7)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 21 Nov 2017 09:16:53 +0100 (CET)
X-Miltered: at korolev with ID 5A13E0F5.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A13E0F5.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 : 5A13E0F5.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: 
Subject: Re: [babel] draft-ietf-babel-source-specific-01
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 08:16:57 -0000

Hi Denis,

> * In the abstract: there is no such thing as Experimental Track, it is =
just Experimental.

Thanks for your feedback, applied.

> * In Section 7.1: it may be useful to note that in a well-formed =
Source Prefix sub-TLV the value of Length is at least 2.

The other documents does not have such precision so I prefer to let is =
as is.

:-)
Matthieu


From nobody Wed Nov 22 20:56:57 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5359412EBF8 for ; Wed, 22 Nov 2017 20:56:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYapnVCLhHYU for ; Wed, 22 Nov 2017 20:56:54 -0800 (PST)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E43812EBF7 for ; Wed, 22 Nov 2017 20:56:54 -0800 (PST)
Received: by mail-ot0-x233.google.com with SMTP id b49so15383689otj.5 for ; Wed, 22 Nov 2017 20:56:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=P8xkH+y5KQdIHAqse/yiTLdhAdkyrjQwzh41QnXsjIY=; b=tZeLiD1cM6u7aQS0+cHnozx8/2isiTbexUi0ZDRE6qbSAbavKYLSjidmMNKAmiWQ1t 4tmfLNl6pXnsNmKAm3iKiNtKzJ2gevBxekseAMnUn4YbPvEHtEA+SMPjoIjv+XnaJR8q A/+wXcVnqT0scJmuGUlqCajkB5McGkcTzMpg4vo+MWcF03qm+Yx8zqDbzTULC7DXbIb7 3yil6dzivPmTd7ooxAfnoJn7vHSZBHwYz5raCisTrhSPwDIa0ZE1eYmhRfeIZfZ1Er/z 1MXm9nc5q+n2MARRwTx1pTnwEoQzoDLcHqk4b9O2Puwgis9dfyqCSmGAxYOzeQy5sLg5 tCaA==
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=P8xkH+y5KQdIHAqse/yiTLdhAdkyrjQwzh41QnXsjIY=; b=NMpYLnzJEs4k2JIAUoAB9dY31U/1bUQ7jxEHXEsDk+8eBqYsoM1DTzfMt49EV3Bprr 7Tv4cVUrJGZPeeyj5rTWG+iTTilX10pfs1FR1mfX5QNoWUNr39n7VfwYsObj2xeLFc3z MgrpZsz+qyC32u8rDESbdwGvMMlSlfzXctRj0MigNZs9mhPFSEFXKsFY3KvtC57ROJ+U IrlLhatT8gOMTbpLrOACFuFPPguhWDKs49q6yPfTxjcB+WmgCSmI4NP2XU1Ok/0ekacX MrAxfv57r+QNrPCRaQKZAVJbu5RBrfqEUUbNZRZdAbepmhKk9ud+RtWsPAsKUiU7VqdP VvPg==
X-Gm-Message-State: AJaThX4RWxFNtKgt0XCe6XFP50yIX19fmDbw2y6/KSqi5VjB67kWM1TL 1P1TvGZX4ssU8xtCI4k3efjI0RoDLBErLqoaQlc1/g3B
X-Google-Smtp-Source: AGs4zMbJEuxs0KbSgqVw6dQ4qS6BZEMbWIxEZ+I2zT6bnzm9ZojEHOwXCO/cUWPWIEcgOoe84VS+dCc38TSLZHoX1HA=
X-Received: by 10.157.66.216 with SMTP id c24mr16167579otj.332.1511413013148;  Wed, 22 Nov 2017 20:56:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.73.194 with HTTP; Wed, 22 Nov 2017 20:56:37 -0800 (PST)
From: Donald Eastlake 
Date: Wed, 22 Nov 2017 23:56:37 -0500
Message-ID: 
To: Babel at IETF 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [babel] Draft Babel Minutes uploaded
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 23 Nov 2017 04:56:55 -0000

Draft minutes of the Babel WG meeting in Singapore have been uploaded
to the meeting materials:
https://datatracker.ietf.org/meeting/100/materials/minutes-100-babel/

Thanks to Barbara Stark for taking the raw minutes.

Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


From nobody Mon Nov 27 07:20:58 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CEE1270FC for ; Mon, 27 Nov 2017 07:20:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khKSHsWkzj6E for ; Mon, 27 Nov 2017 07:20:55 -0800 (PST)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61172126BF3 for ; Mon, 27 Nov 2017 07:20:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1511796051;  s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1367; bh=sbgpOkS1pRUpADpgkK3kQkz7vKb/j0FwnjrDIb/GcSg=; b=Hz/v1LRyE1XMZUz8ip68wK91vXNgTlvlez+khQwYSjyej0M1Zz34TOQoKbGo6a38 e90+roJg7aMc8ZeRu35fyB3XLEPkTVq4U8vXF8HV5evWjenZY5u2QI96E06qGOwhkx6 jF8L/djLelUIXxlbkADZIa1mRD4/um6j9YJdH3F8=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1511796051896835.1590746025062; Mon, 27 Nov 2017 07:20:51 -0800 (PST)
Date: Mon, 27 Nov 2017 15:20:51 +0000
From: Denis Ovsienko 
To: "Babel at IETF" 
Message-ID: <15ffe110fb5.d41d57ec11445.1975503389498519436@ovsienko.info>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: 
Subject: Re: [babel] Draft Babel Minutes uploaded
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 27 Nov 2017 15:20:57 -0000

---- On Thu, 23 Nov 2017 04:56:37 +0000 Donald Eastlake  wrote ---- 
>Draft minutes of the Babel WG meeting in Singapore have been uploaded 
>to the meeting materials: 
>https://datatracker.ietf.org/meeting/100/materials/minutes-100-babel/ 
> 
>Thanks to Barbara Stark for taking the raw minutes. 

Thanks for posting the minutes. Those do not include the comments I made on Jabber, so let me follow up on the mailing list in an attempt to progress some further work.

As far as the Babel security slides from IETF 100 go, I do not oppose the statements made in the document. My main concern is that the working group has already had this same discussion at IETF 96 ([1] page 13) and roughly agreed where to go next. Shall we actually proceed and discuss the options in particular technical terms? If yes, this brings us to the next question.

A DTLS-based Babel security design has been discussed as an option since at least the pre-WG BoF, but a public specification of it still does not exist (corrections are very welcome). Would anybody like to specify (and defend if necessary) the potential DTLS-based mechanism for Babel? Ideally this should be an I-D but even a few pages of quality technical description on the mailing list would be better than nothing.


1: https://www.ietf.org/proceedings/96/slides/slides-96-babel-2.pdf

-- 

    Denis Ovsienko





From nobody Mon Nov 27 08:30:51 2017
Return-Path: <7riw77@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCF9126C3D for ; Mon, 27 Nov 2017 08:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.55
X-Spam-Level: **
X-Spam-Status: No, score=2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22DAT4yutohD for ; Mon, 27 Nov 2017 08:30:48 -0800 (PST)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4727F12426E for ; Mon, 27 Nov 2017 08:30:48 -0800 (PST)
Received: by mail-it0-x22f.google.com with SMTP id n134so21774823itg.1 for ; Mon, 27 Nov 2017 08:30:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=KVMmGOWdiOAiHeBO5MAxNSwPLKyx0wkxxYWk6FtEdmA=; b=ZbHVhWjULyvmZeoajdPfVxRKYsrV31f/RsyZpBBUV66rVRJni6QN1FyveV04Rf5aAZ ic1ho4aF5FJxN8wgbB0FBPuSheZKBJmTSRobg9ivAeU+91EUFEWnfJ38j9o+eHFrrtbp LJFf/3iPN9fL6OE4Q2S41QOrv+zEyemh6HSiIZXdmSbc4PNlvY/fIPxi671/5G9rZpyd VCHBV63DG+6bzBBWu+o/3NIHfzywcEX3FzHM2FcSpk+LLJO/LmNR5/HLgIRLH/yMqA8e ZywY0C83/RVMa3WtgBuQgoY7zD77Cw1sMSNis2xdraiygCdpZs9+Em0svWg/TEa8Fg/l Z9oQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=KVMmGOWdiOAiHeBO5MAxNSwPLKyx0wkxxYWk6FtEdmA=; b=ShoOuuqvumV2c9XqO1aUu4SpQDYiNl/r2qytsIOnr5V87ZTEhPUbpAHbxcL3VzcmXj h9LRemXOrht862ND9W9+/FeSOoc7ia2ZpJY4bdzaUAAa/wR6oxEqSXr/Ae8XXZJXg1/i d2TZVBFKz5vyOSWZ3sgsL8G0TN7W2D1H1AfXY7RrbetFh6rkgiX/RhFrhhmJ5tCeYd4Y 2Ux5ErhBuuKyjm98+1Menwxaf5eGdvvJO/KUNUn9PIQKslc1Hi8DpH5ZPUsKj/MJ+isy jC3Gxf8Q5qjPTnwOTIYw1iSVNi7RA5p9y2st7Guo77fuc4aRquUSJhRxOj7nf5dWBGY4 SrRg==
X-Gm-Message-State: AJaThX48UegyE4YdP5ikTY0howaOl4WKm0z9y9CnBGegD6N+wbAoMmf4 LB7fbdiMmzEqPtg63u0+SATDqQ==
X-Google-Smtp-Source: AGs4zMb/tpwB8UszJqOazu9twlBOTWh9bnHsGMaeCShAefttjPUY5TLiUmD8ujJ6ufni6Mh9K+M9Cg==
X-Received: by 10.36.48.82 with SMTP id q79mr31870044itq.75.1511800247092; Mon, 27 Nov 2017 08:30:47 -0800 (PST)
Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id j190sm7714368itb.35.2017.11.27.08.30.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 08:30:46 -0800 (PST)
From: "Russ White" <7riw77@gmail.com>
To: 
Cc: , , "'Donald Eastlake'" 
Date: Mon, 27 Nov 2017 11:30:44 -0500
Message-ID: <04cc01d3679d$136c56f0$3a4504d0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdNnnNuuQ9O/UddsT+6Msp149xNSHw==
Content-Language: en-us
Archived-At: 
Subject: [babel] Thoughts on rfc6126bis
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-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, 27 Nov 2017 16:30:49 -0000

Y'all --

I read through the draft again, and ran into a couple of small things -- =
the operation of EIGRP as described in this doc has always bothered me, =
I finally went through and thought about what's wrong with it, and =
provided some wording around this. Some other minor nits, as well.

=F0=9F=98=8A

Russ

=3D=3D
As many routing algorithms, Babel computes costs of links between any =
two neighbouring nodes, abstract values attached to the edges between =
two nodes.  We write C(A, B) for the cost of the edge from node A to =
node B.
  =20
I think this is probably missing a word? Perhaps "Babel uses an abstract =
value to represent the cost of the link between any two nodes," or some =
such?
  =20
=3D=3D
Given a route between any two nodes, the metric of the route is the sum =
of the costs of all the edges along the route.  The goal of the routing =
algorithm is to compute, for every source S, the tree of routes of =
lowest metric to S.

Because the shortest path is always loop free -- I don't know if this is =
worth mentioning here, but it might be useful for some readers.

=3D=3D
At this point, the whole network must be rebooted in order to solve the =
starvation; this is essentially what EIGRP does when it performs a =
global synchronisation of all the routers in the network with the source =
(the "active" phase of EIGRP).

The active process is not a "network reboot," but rather it's very =
similar to what BABEL does. To describe the EIGRP process --

1. A route is lost, resulting in starvation
2. The router losing the route marks the destination as active
3. The router then sends a query to each neighbor for the now active =
route
4. The neighbor examines its local table for an alternative route which =
meets the local feasibility condition
5. If such a route to the destination is found, the router responds to =
the query with this information
6. If no such route is found, the router will send queries to its =
neighbors to continue the search

This is very similar to what BABEL does, but with two differences. =
First, there are no sequence numbers. Instead of sequence numbers, EIGRP =
assumes a route received as part of an answer to a query is always newer =
than the original route (and hence the feasibility condition may be =
reset). Second, rather than sending just the originator of the original =
route a request for a new route, EIGRP spreads the request out to all =
neighbors, so any alternative path will work.

I think what the paragraph is trying to refer to is the (old) Stuck in =
Active (SIA) process, not the active process. What happens here is if an =
EIGRP router is active on a particular destination, and does not receive =
an answer from a neighbor it has sent a query to for a long time, it =
will reset that specific neighbor state (assuming the neighbor is no =
longer responding). This still is not a "network reboot," of course, but =
it is more drastic than other possible solutions. In more recent code, =
EIGRP does not reset the neighbor adjacency, but rather queries again =
(the SIA query process), and again treats any route received in response =
to this query as newer than the no longer useable route (because of the =
topology change).=20

I would change this to -- "EIGRP marks a route active, transmitting a =
diffusing query through the network to find an alternative route in the =
case of starvation." At some later point, it might be worthwhile to =
describe the differences between the EIGRP process and the BABEL =
process.


From nobody Mon Nov 27 16:16:32 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC31A124207 for ; Mon, 27 Nov 2017 16:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0l0lUg5kX0E for ; Mon, 27 Nov 2017 16:16:29 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE499128AA1 for ; Mon, 27 Nov 2017 16:16:28 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAS0GQMW002292; Tue, 28 Nov 2017 01:16:26 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 8E770EB217; Tue, 28 Nov 2017 01:16:26 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id MaMuFaw6C8S7; Tue, 28 Nov 2017 01:16:21 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 34197EB215; Tue, 28 Nov 2017 01:16:21 +0100 (CET)
Date: Tue, 28 Nov 2017 01:16:21 +0100
Message-ID: <87mv37b6lm.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: Denis Ovsienko 
Cc: "Babel at IETF" 
In-Reply-To: <15ffe110fb5.d41d57ec11445.1975503389498519436@ovsienko.info>
References:  <15ffe110fb5.d41d57ec11445.1975503389498519436@ovsienko.info>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 28 Nov 2017 01:16:26 +0100 (CET)
X-Miltered: at korolev with ID 5A1CAADA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A1CAADA.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 : 5A1CAADA.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: 
Subject: Re: [babel] Draft Babel Minutes uploaded
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 00:16:31 -0000

Hi Denis,

> A DTLS-based Babel security design has been discussed as an option since
> at least the pre-WG BoF,

Note that this is just an option.  I'd very much like to see a revised
revision of RFC 7298 (one without the security issue you outlined in
Prague).

Denis, both RFC 7298 and DTLS have a niche: RFC 7298 is great if you're
implementing from scratch, or when you want to use multicast; DTLS is
great if you already have a DTLS stack and you don't care about multicast.

> but a public specification of it still does not exist (corrections are
> very welcome). Would anybody like to specify (and defend if necessary)
> the potential DTLS-based mechanism for Babel?

I think we should implement it first, and specify later.  Antonin and
myself are working on it, but don't expect anything to happen until after
exam season is over (in January).

> Ideally this should be an I-D but even a few pages of quality technical
> description on the mailing list would be better than nothing.

Once we have an implementation, we'll write up an Internet Draft.  I'll
welcome co-authors, assuming they are active implementers.

-- Juliusz


From nobody Tue Nov 28 08:06:23 2017
Return-Path: 
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97991270B4 for ; Tue, 28 Nov 2017 08:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owX4OX05NXVC for ; Tue, 28 Nov 2017 08:06:18 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BDF126B72 for ; Tue, 28 Nov 2017 08:06:18 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vASG6CMl020805; Tue, 28 Nov 2017 17:06:12 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A48EDEC873; Tue, 28 Nov 2017 17:06:12 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 6CkIYI3I-ua9; Tue, 28 Nov 2017 17:06:06 +0100 (CET)
Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CF64BEB215; Tue, 28 Nov 2017 17:06:06 +0100 (CET)
Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1eJiOc-0004V4-IW; Tue, 28 Nov 2017 17:06:06 +0100
Date: Tue, 28 Nov 2017 17:06:06 +0100
Message-ID: <7ivahus80h.wl-jch@irif.fr>
From: Juliusz Chroboczek 
To: "Russ White" <7riw77@gmail.com>
Cc: , , "'Donald Eastlake'" 
In-Reply-To: <04cc01d3679d$136c56f0$3a4504d0$@gmail.com>
References: <04cc01d3679d$136c56f0$3a4504d0$@gmail.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 28 Nov 2017 17:06:12 +0100 (CET)
X-Miltered: at korolev with ID 5A1D8974.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A1D8974.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 : 5A1D8974.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: 
Subject: [babel] About EIGRP [was: Thoughts on rfc6126bis]
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 16:06:22 -0000

>     At this point, the whole network must be rebooted in order to solve
>     the starvation; this is essentially what EIGRP does when it performs
>     a global synchronisation of all the routers in the network with the
>     source (the "active" phase of EIGRP).

I am open to a different formulation, but I don't really see a good way of
keeping the intent while remaining reasonably concise.  I guess I could
replace "the whole network" with "the whole starving subtree", which would
be closer to what EIGRP does.

> The active process is not a "network reboot," but rather it's very
> similar to what BABEL does.

That's an interesting debate.

[...]

> This is very similar to what BABEL does, but with two
> differences. First, there are no sequence numbers. Instead of sequence
> numbers, EIGRP assumes a route received as part of an answer to a query
> is always newer than the original route (and hence the feasibility
> condition may be reset). Second, rather than sending just the originator
> of the original route a request for a new route, EIGRP spreads the
> request out to all neighbors, so any alternative path will work.

I think that is very different from what Babel does.  In order to be able
to clear the old feasibility information, EIGRP must perform a synchronisation
of the whole sub-tree that is suffering from starvation.  It is my
understanding that all the starving routers freeze until they receive
confirmation that the whole subtree has cleared their routes.

So there's synchronisation over an unbounded number of nodes --
essentially a reboot of the starving subtree.  Whence the formulation
quoted above.

This is very different from what Babel does, since Babel is designed to
avoid synchronisation.  In Babel, a request is sent out, and a new route
becomes usable as soon as a new sequence number is received -- no need to
wait for the other neighbours to acknowledge, so a slow or crashed router
will not delay reconvergence as long as faster routers are available to
forward the sequence number.

> I think what the paragraph is trying to refer to is the (old) Stuck in
> Active (SIA) process, not the active process.

I'm not entirely clear on what SIA is, since EIGRP folks are not very keen
on discussing it.  My understanding is that the synchronisation required
by the active phase does not necessarily terminate (a router could crash
between receiving a request and sending the acknowledgment), and in this
case, the network will deadlock until the SIA timeout triggers.  But
I could be wrong.

> In more recent code, EIGRP does not reset the neighbor adjacency, but
> rather queries again (the SIA query process), and again treats any route
> received in response to this query as newer than the no longer useable
> route (because of the topology change).

So basically restarting the active phase instead of dropping the
neighbour?  There's still a timeout dependent on the slowest router in the
starving component, right?

> I would change this to -- "EIGRP marks a route active, transmitting
> a diffusing query through the network to find an alternative route in
> the case of starvation."

I think that is less informative than what I've written.  Does changing
"the whole network" to "the starving subtree", as suggested above, fix it
for you?

-- Juliusz