From nobody Tue May 7 08:32:41 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F06120175; Tue, 7 May 2019 08:32:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <155724315316.21107.17535758254240318344@ietfa.amsl.com> Date: Tue, 07 May 2019 08:32:33 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-09.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 15:32:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : The Babel Routing Protocol Authors : Juliusz Chroboczek David Schinazi Filename : draft-ietf-babel-rfc6126bis-09.txt Pages : 61 Date : 2019-05-07 Abstract: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-09 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 30 09:11:30 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEE2120151 for ; Thu, 30 May 2019 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBw2ymFJH0ON for ; Thu, 30 May 2019 09:11:26 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 83A80120141 for ; Thu, 30 May 2019 09:11:26 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id m15so6577517ljg.13 for ; Thu, 30 May 2019 09:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EckkHD57fdxtOCu+lxpdjb+Xp19BqbgtxvhHsx+o6o8=; b=TICE1GpK7JmDWZtscu+Xh1mGFbWslV/U+qC6HAahnFKV5CYhu++vtWJ2WfN3DqH1C5 1yQQnqhwrOAKFeSY2Dj1LXXQs80pSv6yjjYp+UTHVrlLjH1ZRP1KA87qAUi/mx56GvWM 3h7QbrSiVNqOxT85Paa47USlO3TsTbiJ8blrZ0t8fjzihks95+pcjJ8KSSHiW9RqVvZd YYenlhHmrWsIAKF9CYcKM4W2/Yy9GvYjsInrhAEBoQo3npj2ocz5Utt8fHBhbnOB/daf 7gzkMS1FxiMc+VIU48xRejd3WRsDzk2Ke9pF4snpfUWYPfYq0UggnGCBetYR8i16dAJ9 Mmew== 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=EckkHD57fdxtOCu+lxpdjb+Xp19BqbgtxvhHsx+o6o8=; b=haA/TpPCNB9Ii+TwCNGb82qR551Eia14yaxjv6vmHmk7ucznuA2gn8Kib6V5laFBVs lRHfoxid5M4HROhlS/hrKwqrwh484m57Hz+hvODwhfRtOJNwNkfXZrq7fhpMVs3CqJOf 6ofuIye2bkzjwKBFQAYRywMz6SJ3BG7mJLK+SyOCe6vheKkX5okJZbBLlB9fCEj0/fAG N2aFP6j/TTLeTcZEsR17F7ahPHzF0PMnYr//zKyRfy6x7d9UXCtoy5Bc2YOkUIwVEq5s EbXZJL+OMOhz0Y+yoYZPwdWrAHE9HGWpo45hnn5UfIz3jzcfl49N/aHVvCYmYIMnJCvi /ujA== X-Gm-Message-State: APjAAAVU8ovM2mu0KgO9txgF6gjhFly+oJMreSu45TM47k9jj4O9oJxv BNXcY7xptsAb7b1sMoegz0zLfWmUttIEgzgajAfNJWKGFxI= X-Google-Smtp-Source: APXvYqyo6UUhKOUhqMPCjneuZGz0nawHxx3jTXbrCgk3sMqBl30tGGq+dzHKGpaovE7goHuvBWU4K2uGpekDMdKPvVE= X-Received: by 2002:a2e:890c:: with SMTP id d12mr2577229lji.107.1559232684450; Thu, 30 May 2019 09:11:24 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Thu, 30 May 2019 18:11:13 +0200 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000476818058a1d264b" Archived-At: Subject: [babel] Babel over DTLS and UDP ports X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 16:11:28 -0000 --000000000000476818058a1d264b Content-Type: text/plain; charset="UTF-8" Hi Babel enthusiasts, As currently documented , Babel over DTLS uses two UDP listening ports: - 6696 for regular unencrypted Babel packets - a separate port (number TBD) for Babel-over-DTLS packets When the authors requested the new port from IANA, we received some pushback. The position of the IANA port expert was that UDP ports are a scarce resource and they strongly prefer to not allocate them unless it is necessary. So the question for the Babel WG is: is the separate port necessary? One possible solution could be for us to have unencrypted packets and DTLS packets share the same port. For that we can leverage the fact that all Babel packets start with a first byte set to 42, and say that DTLS packets use the same port, prefixed with 43 instead of 42. What are people's thoughts? In particular, if you have an implementation of Babel over DTLS (or if you are considering building one), do you think the proposal above could be fit into your implementation? Thanks, David --000000000000476818058a1d264b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Babel enthusiasts,

= As current= ly documented, Babel over DTLS uses two UDP listening ports:
= - 6696 for regular unencrypted Babel packets
- a separate port (n= umber TBD) for Babel-over-DTLS packets

When the au= thors requested the new port from IANA, we received some pushback. The posi= tion of the IANA port expert was that UDP ports are a scarce resource and t= hey strongly prefer to not allocate them unless it is necessary. So the que= stion for the Babel WG is: is the separate port necessary?

One possible solution could be for us to have unencrypted packets = and DTLS packets share the same port. For that we can leverage the fact tha= t all Babel packets start with a first byte set to 42, and say that DTLS pa= ckets use the same port, prefixed with 43 instead of 42.

What are people's thoughts? In particular, if you have an implem= entation of Babel over DTLS (or if you are considering building one), do yo= u think the proposal above could be fit into your implementation?

Thanks,
David
--000000000000476818058a1d264b-- From nobody Thu May 30 09:17:55 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8C612008D for ; Thu, 30 May 2019 09:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylPkmq-drab0 for ; Thu, 30 May 2019 09:17:51 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4421012015A for ; Thu, 30 May 2019 09:17:50 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id u186so10352842ith.0 for ; Thu, 30 May 2019 09:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AO38OYhQxITt98E1YSuOBxX9+jYe6gL9GhENTZeChrs=; b=PBCSaernu1ZQ1TeICdgwOuKqZJYXkr/7X6zJ6AxeSXtbGhaJzon6qgVtXxde13eern CUpiveD/cNeEAQpTy08ghwMpPhdWHlpJLlR5NDO8C5NVf9t57uo+dYC3UgeXDSvaQV/0 flqQyPNdtaJI+V6hhT3ZdjQlOiVW350bdYyetkTffQzoOEE8nCloaHzg/hwO/lIyl6N0 5h2Cdq95oBTDJuSjwEngiIgHFlHTZxQxV57Afd9FqXuAVtEgaQUV7TBX95zoDNJKrFIj NKGUFEglalmT2zWT7yE3ctJJGMDy8OEnDFF3zEz3t19ynN0Zx0fxV4Ibz45MGwni4Ng7 ICnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AO38OYhQxITt98E1YSuOBxX9+jYe6gL9GhENTZeChrs=; b=QXoT8yfdBWFcaAgihG97y0L/W9lrFLL0gkfITkKh68+HafPPPKi3ZvkE4CJpkAej1/ oCC+zNOfPvjEcOELyCWwF08TinTvM++d5vrNF6E9EE5mkXhnVPptNwfmhcPXx6h09kSA FJT8JYMUvVYo0B4ZJ8Up+4IDAIFCkLfAg711R+iU8j9P/AbQSAgUdp9cyWQNkGZg+FTT vXBwhpxRbmBSLV7xEkzlM1pgDy7ajreOZLHCPWfJ4weueU1AQdp9hjWUVqctxnHhC3M+ KOBgiUj8OFvX05kenZUG8WnmGtGAXFPI1gXJ2cDLmqm3JtzpByHT9Lso6Embe/RKf710 IYGw== X-Gm-Message-State: APjAAAVV6M/GYcECvqHQJIgtKvmBkt3D/073nehWQsvkiAzZpoLiubpd 2WxC2WvM0ILbP1BMOlOxXzJL0dXvAxYVaLDyY8E= X-Google-Smtp-Source: APXvYqznzppy23VEMiJtpAfyWyssLck2k3ciW72M69lQF0j368kXhbnuMZbneLAZxhhI5+h6dD2ggM56xPUlON6r4N4= X-Received: by 2002:a24:ac0a:: with SMTP id s10mr3998426ite.60.1559233069522; Thu, 30 May 2019 09:17:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Thu, 30 May 2019 09:17:38 -0700 Message-ID: To: David Schinazi Cc: Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel over DTLS and UDP ports X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 16:17:54 -0000 On Thu, May 30, 2019 at 9:11 AM David Schinazi w= rote: > > Hi Babel enthusiasts, > > As currently documented, Babel over DTLS uses two UDP listening ports: > - 6696 for regular unencrypted Babel packets > - a separate port (number TBD) for Babel-over-DTLS packets > > When the authors requested the new port from IANA, we received some pushb= ack. The position of the IANA port expert was that UDP ports are a scarce r= esource and they strongly prefer to not allocate them unless it is necessar= y. So the question for the Babel WG is: is the separate port necessary? > > One possible solution could be for us to have unencrypted packets and DTL= S packets share the same port. For that we can leverage the fact that all B= abel packets start with a first byte set to 42, and say that DTLS packets u= se the same port, prefixed with 43 instead of 42. So that is in the clear? > > What are people's thoughts? In particular, if you have an implementation = of Babel over DTLS (or if you are considering building one), do you think t= he proposal above could be fit into your implementation? I rather liked it over udp-lite. > > Thanks, > David > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Fri May 31 06:14:12 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011661200DB for ; Fri, 31 May 2019 06:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyL-4AhC6XPC for ; Fri, 31 May 2019 06:14:08 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9279E120075 for ; Fri, 31 May 2019 06:14:08 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x4VDE3q7001797; Fri, 31 May 2019 15:14:03 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E164570E3C; Fri, 31 May 2019 15:14:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id tpDCQhP8EjWb; Fri, 31 May 2019 15:14:04 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1BDE670E3A; Fri, 31 May 2019 15:14:04 +0200 (CEST) Date: Fri, 31 May 2019 15:14:03 +0200 Message-ID: <87tvda7omc.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Babel at IETF In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 31 May 2019 15:14:03 +0200 (CEST) X-Miltered: at korolev with ID 5CF1289B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5CF1289B.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 : 5CF1289B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel over DTLS and UDP ports X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 13:14:11 -0000 > When the authors requested the new port from IANA, we received some pushback. > The position of the IANA port expert was that UDP ports are a scarce resource > and they strongly prefer to not allocate them unless it is necessary. In a healthy technical organisation, the administration helps the technical folks get their stuff done. An organisation is ossified if the bureaucacy feels they have the right to dictate the technical solutions. If there are technical reasons to use a single port, we should state them. Under no circumstances should we agree to change our protocol in order to make the bureaucrats happy. > So the question for the Babel WG is: is the separate port necessary? Antonin's original implementation implementation used a single port: https://datatracker.ietf.org/meeting/101/materials/slides-101-babel-babel-over-dtls-00 > One possible solution could be for us to have unencrypted packets and DTLS > packets share the same port. For that we can leverage the fact that all Babel > packets start with a first byte set to 42, and say that DTLS packets use the > same port, prefixed with 43 instead of 42. Yes, that's what I was arguing for back in 2018. However, I was put in the minority by a number of wise people: - David argued that the whole point of DTLS is to use a standard DTLS stack, and some DTLS stacks don't support using a single port for both encrypted an cleartext traffic; - David pointed out that Apple's DTLS implementation doesn't support this mode of operation; - Donald added that it is usual for IETF protocols to use separate ports. If the above points no longer stand, then please explain what has changed since 2018. If these points still stand, then it is our duty to make the right technical decision, IANA's impotence notwithstanding. We have a number of options: - go speak with IANA again, stating clearly that using distinct ports reflects WG consensus; - should that fail, we could use an ephemeral port for DTLS, announce it as a sub-TLV of multicast Hello (recall that DTLS uses unicast only); - should that be considered to fragile, we can publish the draft with no port assignment, and have implementations squat an unallocated port. > What are people's thoughts? None that can be expressed without profanity. (Please have a look at the IANA UDP port registry -- thousands of ports have been allocated to completely undocumented obscure protocols, and they're refusing to allocate a single port for a standards track document?) -- Juliusz From nobody Fri May 31 06:25:34 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12A51200CD for ; Fri, 31 May 2019 06:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8LceNBW5jFs for ; Fri, 31 May 2019 06:25:30 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5888D12002E for ; Fri, 31 May 2019 06:25:30 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id m22so9385422ljc.3 for ; Fri, 31 May 2019 06:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HsQyAyLTpJ+ls/iOCz7w8BM3Y0mCyn7Ezj1A2SIm00k=; b=K4hHoEEJ3EjJACWETI/2jRn6VrW/8DqMxc95h0STKQMDCMvpY5ZfZeNeJeElqn206c 27EMa2UIcdXNuNa1mGDLZiNwH/1xWZLGwnejjqBzNAQsIK4hd6KJRKLTZVOgSmDg5bmu OUVAj1+4KhBtzxhXOm9dmPcknlDd6RcA4J0PqezTNytd2MHFHirbrf5oLB9C4wymGouX QQyV12a4GZmkbyp/DXGTVyuu5M6EiI/b4xpjlfRof9gE7pDgbqOiQwO4/DWX7rmUNrIC TmofCANs7tnNONmPizrhROOKQeud29FXqLIHCUpeLTcRH43SpeTzZJjyIJHQxq4XmeVb aQyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HsQyAyLTpJ+ls/iOCz7w8BM3Y0mCyn7Ezj1A2SIm00k=; b=kQS9q6wr3wPSwr6Nb1zOz3krmm49OOdGlUb41TjTYtJbwobIf0xZdWupLE9Zpiro4W UCjC7FCt6qTFvDSiok5lctsSimvJaAdaMNlvCWDZ+aHsPcgcxiBI2mdnMK/pXgsVu0Vi zU2NH4DsBmRbiCMRFcGKQHuBBXH7azq5USPj0t6HDWMGs2tFBxNcx3fQQdldbSTA+d6X f4ZKK4PwH+MmtsZbXDXxwQjGh41GZgh8k8BAuDweB87ophWEdX/xQsUnHnMDuKyxv6li Zz8brnP3pTNV7GQ6mB16TEqsl9GQ4YMPAs09wGr1dOA9BwZ0M/TZfNMsfylBCb+lrl5N of6w== X-Gm-Message-State: APjAAAUBEFiMHVPtwygGVT76ThxEkwOAiNpXa//Qz0nbIYCPsfoOShEj cWU6BaDaNCozaYVoOQaTJkRyF1Quo63nekDEymw= X-Google-Smtp-Source: APXvYqyJ60aww0fsupkm/PWTisMKgqxlkwv1tc4dhJ2kywMe2OZwK2vbjiULIENVw2+g9JsDM8/8JsMWcJ04RQlYnpU= X-Received: by 2002:a2e:81d9:: with SMTP id s25mr6050514ljg.139.1559309128595; Fri, 31 May 2019 06:25:28 -0700 (PDT) MIME-Version: 1.0 References: <87tvda7omc.wl-jch@irif.fr> In-Reply-To: <87tvda7omc.wl-jch@irif.fr> From: David Schinazi Date: Fri, 31 May 2019 15:25:17 +0200 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000b47cfe058a2ef2f2" Archived-At: Subject: Re: [babel] Babel over DTLS and UDP ports X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 13:25:33 -0000 --000000000000b47cfe058a2ef2f2 Content-Type: text/plain; charset="UTF-8" Hi Juliusz, Thanks for your passionate response :-) To clarify my earlier email, the IANA port expert gave their opinion, and I've been made aware that as expert they provide knowledgeable opinions but do not hold power over the final outcome. The powers that be wanted there to be a new conversation on the Babel mailing list about the pros and cons of using a new port, given the expert's opinion. If it is still the consensus of the Babel WG that allocation of a new port is critical to some implementations and will facilitate deployment of a secure version of the protocol, and the IESG agrees that this consensus was reached, then once the IESG moves the document forward the IANA considerations section will apply and a new port will be allocated. Now, speaking as implementor of Babel (as opposed to draft author), I strongly believe that a new port will make a difference in the success of this protocol. Juliusz phrased the reasons why quite well. Thanks, David On Fri, May 31, 2019 at 3:14 PM Juliusz Chroboczek wrote: > > When the authors requested the new port from IANA, we received some > pushback. > > The position of the IANA port expert was that UDP ports are a scarce > resource > > and they strongly prefer to not allocate them unless it is necessary. > > In a healthy technical organisation, the administration helps the > technical folks get their stuff done. An organisation is ossified if the > bureaucacy feels they have the right to dictate the technical solutions. > > If there are technical reasons to use a single port, we should state them. > Under no circumstances should we agree to change our protocol in order to > make the bureaucrats happy. > > > So the question for the Babel WG is: is the separate port necessary? > > Antonin's original implementation implementation used a single port: > > > https://datatracker.ietf.org/meeting/101/materials/slides-101-babel-babel-over-dtls-00 > > > One possible solution could be for us to have unencrypted packets and > DTLS > > packets share the same port. For that we can leverage the fact that all > Babel > > packets start with a first byte set to 42, and say that DTLS packets use > the > > same port, prefixed with 43 instead of 42. > > Yes, that's what I was arguing for back in 2018. However, I was put in > the minority by a number of wise people: > > - David argued that the whole point of DTLS is to use a standard DTLS > stack, and some DTLS stacks don't support using a single port for both > encrypted an cleartext traffic; > - David pointed out that Apple's DTLS implementation doesn't support > this mode of operation; > - Donald added that it is usual for IETF protocols to use separate ports. > > If the above points no longer stand, then please explain what has changed > since 2018. > > If these points still stand, then it is our duty to make the right > technical decision, IANA's impotence notwithstanding. We have a number of > options: > > - go speak with IANA again, stating clearly that using distinct ports > reflects WG consensus; > - should that fail, we could use an ephemeral port for DTLS, announce it > as a sub-TLV of multicast Hello (recall that DTLS uses unicast only); > - should that be considered to fragile, we can publish the draft with no > port assignment, and have implementations squat an unallocated port. > > > What are people's thoughts? > > None that can be expressed without profanity. > > (Please have a look at the IANA UDP port registry -- thousands of ports > have been allocated to completely undocumented obscure protocols, and > they're refusing to allocate a single port for a standards track document?) > > -- Juliusz > --000000000000b47cfe058a2ef2f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

Thanks for= your passionate response :-)

To clarify my earlie= r email, the IANA port expert gave their opinion, and I've been made aw= are that as expert they provide knowledgeable opinions but do not hold powe= r over the final outcome.
The powers that be wanted there to be a= new conversation on the Babel mailing list about the pros and cons of usin= g a new port, given the expert's opinion.
If it is still the = consensus of the Babel WG that allocation of a new port is critical to some= implementations and will facilitate deployment of a secure version of the = protocol, and the IESG agrees that this consensus was reached, then once th= e IESG moves the document forward the IANA considerations section will appl= y and a new port will be allocated.

Now, speaking = as implementor of Babel (as opposed to draft author), I strongly believe th= at a new port will make a difference in the success of this protocol. Juliu= sz phrased the reasons why quite well.

Thanks,
David


On Fri, May 31, 2019 at 3:14 PM Juliusz Ch= roboczek <jch@irif.fr> wrote:
<= /div>
> When the author= s requested the new port from IANA, we received some pushback.
> The position of the IANA port expert was that UDP ports are a scarce r= esource
> and they strongly prefer to not allocate them unless it is necessary.<= br>
In a healthy technical organisation, the administration helps the
technical folks get their stuff done.=C2=A0 An organisation is ossified if = the
bureaucacy feels they have the right to dictate the technical solutions.
If there are technical reasons to use a single port, we should state them.<= br> Under no circumstances should we agree to change our protocol in order to make the bureaucrats happy.

> So the question for the Babel WG is: is the separate port necessary?
Antonin's original implementation implementation used a single port:
=C2=A0 https:/= /datatracker.ietf.org/meeting/101/materials/slides-101-babel-babel-over-dtl= s-00

> One possible solution could be for us to have unencrypted packets and = DTLS
> packets share the same port. For that we can leverage the fact that al= l Babel
> packets start with a first byte set to 42, and say that DTLS packets u= se the
> same port, prefixed with 43 instead of 42.

Yes, that's what I was arguing for back in 2018.=C2=A0 However, I was p= ut in
the minority by a number of wise people:

=C2=A0 - David argued that the whole point of DTLS is to use a standard DTL= S
=C2=A0 =C2=A0 stack, and some DTLS stacks don't support using a single = port for both
=C2=A0 =C2=A0 encrypted an cleartext traffic;
=C2=A0 - David pointed out that Apple's DTLS implementation doesn't= support
=C2=A0 =C2=A0 this mode of operation;
=C2=A0 - Donald added that it is usual for IETF protocols to use separate p= orts.

If the above points no longer stand, then please explain what has changed since 2018.

If these points still stand, then it is our duty to make the right
technical decision, IANA's impotence notwithstanding.=C2=A0 We have a n= umber of
options:

=C2=A0 - go speak with IANA again, stating clearly that using distinct port= s
=C2=A0 =C2=A0 reflects WG consensus;
=C2=A0 - should that fail, we could use an ephemeral port for DTLS, announc= e it
=C2=A0 =C2=A0 as a sub-TLV of multicast Hello (recall that DTLS uses unicas= t only);
=C2=A0 - should that be considered to fragile, we can publish the draft wit= h no
=C2=A0 =C2=A0 port assignment, and have implementations squat an unallocate= d port.

> What are people's thoughts?

None that can be expressed without profanity.

(Please have a look at the IANA UDP port registry -- thousands of ports
have been allocated to completely undocumented obscure protocols, and
they're refusing to allocate a single port for a standards track docume= nt?)

-- Juliusz
--000000000000b47cfe058a2ef2f2-- From nobody Fri May 31 06:36:57 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5051512009C for ; Fri, 31 May 2019 06:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn77L-xXE6uK for ; Fri, 31 May 2019 06:36:52 -0700 (PDT) Received: from mails.bitsofnetworks.org (mails.bitsofnetworks.org [IPv6:2001:912:1800:ff::131]) (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 77C7B120075 for ; Fri, 31 May 2019 06:36:52 -0700 (PDT) Received: from [2001:912:1800:0:f3c3:fd02:8b06:8680] (helo=tuxmachine.localdomain) by mails.bitsofnetworks.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hWhiD-00021j-AV; Fri, 31 May 2019 15:36:49 +0200 Date: Fri, 31 May 2019 15:36:48 +0200 From: Baptiste Jonglez To: babel-users@lists.alioth.debian.org, babel@ietf.org Message-ID: <20190531133648.GB31876@tuxmachine.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) Archived-At: Subject: [babel] Call for participation for BattleMesh V12 (8-14 July 2019, Paris) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-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, 31 May 2019 13:36:55 -0000 --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, The local organization team is proud to announce that this year's Battlemesh will be held near Paris, from 8 to 14 July! The event aims to bring together people from across the globe who are interested in community networks, including wireless mesh network technologies, fiber infrastructure, Do-It-Yourself Internet Access Providers, and more generally how to create and maintain a thriving community of people involved in building their own networks. We envision 7 days full of expert presentations, practical workshops, late-night hacking sessions, and fruitful discussions: whether you are a mesh networking enthusiast, community networking activist, protocol developer, or have an interest in networking in general, come and join us!= =20 More information about the event is available below or on the website: https://www.battlemesh.org/BattleMeshV12 Where =3D=3D=3D=3D=3D Le 6B, 6-10 quai de Seine, 93200 Saint-Denis, France (very close to Paris). GPS: geo:48.93835,2.34259 Map: https://www.openstreetmap.org/?mlat=3D48.93835&mlon=3D2.34259#map=3D18= /48.93835/2.34259 Web: https://www.le6b.fr/ Travel directions: https://www.battlemesh.org/BattleMeshV12#Where What =3D=3D=3D=3D We will have organized talks, workshops and discussion panels on community networks and wireless mesh networks. There will also be more informal activities: cooperative hacking, self-organized projects, and (we hope) delightful conversations! A first draft of the schedule (handle with care!) is available here: https:= //www.battlemesh.org/BattleMeshV12#Talk_Schedule_and_Workshops How to register =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The event itself is free of charge and open for all! However, it makes the organisation much easier if you tell us in advance that you plan to come. To register: https://www.battlemesh.org/BattleMeshV12#How_to_register Current list of participants: https://battlemesh.org/BattleMeshV12/Particip= ants Accommodation package =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For those of you who are looking for a convenient and low cost accommodation option in Paris: we negotiated a special group reservation for 24 people at an hostel. There are still a few beds left, register now before we run out! https://ww= w.battlemesh.org/BattleMeshV12#Accommodation_package Call for participation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We invite participants to propose workshops, talks or panel discussions relating to network infrastructure in general, how it can be built and operated as a common, and how to sustain a community around networking. We welcome contributions that broadly address these questions from any of several perspectives: technical, organisational, economical, regulatory, juridical, political. Deadline: 10 May 2019, now extended to June 7th! To submit an event: https://www.battlemesh.org/BattleMeshV12#Call_for_parti= cipation Endorsements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If your organization wants to support the event by spreading the word, you can endorse the event. For this, just write an article on your website / blog / social media, and send us an email with the link and your logo to: (v12) at (battlemesh) dot = (org) See existing endorsements for a template: https://www.battlemesh.org/Battle= MeshV12#Endorsements Contact =3D=3D=3D=3D=3D=3D=3D * Web: https://battlemesh.org/BattleMeshV12 * Contact email (preferred): v12 at battlemesh.org * Public mailing list: https://ml.ninux.org/mailman/listinfo/battlemesh * IRC: irc.freenode.net #battlemesh * Twitter: https://twitter.com/battlemesh/ * Mastodon: https://toot.aquilenet.fr/@battlemesh12 The Local Organization Team =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 Aube Baptiste Daniele Dash Vi and many other volunteers! --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjVflzZuxNlVFbt5QvgHsIqBOLkYFAlzxLfAACgkQvgHsIqBO LkaBihAAnJr8RzrK/VY2l/WrvM6eKFjzybADJ87l8WuZ7cm8O0xDeeLCoQtSj52z NfVJFRXfpS+GpQs3gtEOG2YnE993qKHWim7oM7qInH2hxrlGivXBEuL6cWu3kglw 43YO2kp9txfqTXzSTyXc5S1x2rSZjW0KhtTN/xSzp2uBx4MGPnoZo7IkeNec9x+0 4BgnVr+tjNofObkYpokNn8rLH/irnmBeBpK9NsPkstM8W7rUENYenuVkrH5rZ3vg qyTniEPz9AHHRugzOFwZwtYA1lnWUD2eW2T1GF5GZsW/l4GMDYxVrdxC2m2vB1ro CW/MY7oyDXSy3gkeuQt/CeGcyoohvVFOz3XvlYdxnqSda8UmALl9LCN2eQGenn2i IAaO2WfSILM/vz/lvzXJlRj6SCBOtpDTqxr2QzYtqAXj4KSWHewTJrNo6K1lZ2jB 4FMCgDYD7auTEchGVjbRxe75ox8kYXveqMzLXsYgbZIhqhLAQLpTlfmyNSqKEylI dfQxBoFrbaB1bo0BzulABpNlFm2X9OshkQ+Mq9Rxmu9kGUmMwYYdg5SfzYwqTweZ tB49qIeAqHv2UMdMMiwzemesGcHjMNWiem9GaIWSVK1834/jrA8KPY+VHaBVQy0O gaTUuUrnGl/tSmX/r15OYRJHrBRRyVum+L6xDlCBlRdFPFu9Wp4= =/dvA -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2--