[manet] Re: draft-ietf-manet-inet-gap-analysis-06.txt
Christopher Dearlove <christopher.dearlove@gmail.com> Mon, 17 August 2026 14:47 UTC
Return-Path: <christopher.dearlove@gmail.com>
X-Original-To: manet@mail2.ietf.org
Delivered-To: manet@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 72F7412B0F304 for <manet@mail2.ietf.org>; Mon, 17 Aug 2026 07:47:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786978057; bh=ZE8Lhw33nSUFowRUaq7HPVa8ecoaxFZauJXKPI5RrGo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=VdGbt+JiVjzQ/8DxhaR3ejnmptaEEEwEmRUJJAhe1I7thcDq61m2YLJtSNK353Mx/ Clp0Dfk9vbCYNvu3S4DiAPvqT5eoeqw9UVwcU64GGESOF3jbP5Wtxdf1KywxJG5nx2 id8DK1j9XJ2xERkc3hhehedwsHDTY6o2+NFxvilU=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level:
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iBMPOfXUe2i for <manet@mail2.ietf.org>; Mon, 17 Aug 2026 07:47:36 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D60C112B0F301 for <manet@ietf.org>; Mon, 17 Aug 2026 07:47:36 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4956242332dso37264055e9.2 for <manet@ietf.org>; Mon, 17 Aug 2026 07:47:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786978050; x=1787582850; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:from:to:cc :subject:date:message-id:reply-to:content-type; bh=HYeg/sElgsN67+pf+UDoqpcC0ck+7TdlJSHabPnNf+I=; b=BpvD6l6OoqRfaf0AKWHEqea3/OCvOS97qaH/KO5dRl/aEWOBJ2bJC7Ugq/tcykZbGv bq4T6dOBt16TaGs7zwU6z6s5pjTApelN30EBmoVBsWfPLHzwl9FNhAhmrNhVqbUbJQFQ /ElI1BpCuM2O+rriAuTyzKI5m0lmjixS24oTfV/YT10rbl37cJ+haUdN9yMZXamGL/ZM CjVFq1g8/NERLo3BciZ6x5Oh11pox6Ma34IUJQmt7OdNCUaq0z2Wa7hLSRej8Ldc/m// qdkJet1s0T70ZdmaDE56SmguFrQWGse4DTd9N0r8TL/ReD0uPOMGspDLcL8dreDOp8bi OzZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786978050; x=1787582850; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HYeg/sElgsN67+pf+UDoqpcC0ck+7TdlJSHabPnNf+I=; b=r5NVZEiZGowO9VdRC/FEhrey/+2DoQh0xJfLKX9ETVtqVbkVhD6pfDDz0EKJoDenmN 93xL91UboH5w5yKKc2O57qUnrBRrl1bs3/+owhGfvf/wVvznNwoiZrG6xB/MoU4eo8RD MrcR+Bvye0j6KBzc41u5FG43e7ivy8Hy97R+RJZn8xIOgzhngKxmCoM8KvYsarcbIBsq rDeGkPS96ZfeD1LS7WsAXLN7jlY80JlZRmwt0CTHB1PlQeYXdzO09G0PEqmEgEsy4UrO 5ltxagiPUx4tZfakh/T/Eh0GDigFP03AdDu9yrhbsS2sUOeSOMKsAwpz3Qp5JGuu4nAy daNg==
X-Gm-Message-State: AOJu0Yw+ySrYvW/knuJ90IEdPnWRnDflgN689UbpvMJRgaXPq+rBeLgb 6xDPXBypN651drN5+CK9BdTr9VFWKiaCKrMzV0mkKvgOfQw0PSMfLnkK
X-Gm-Gg: AR+sD11k7rb1bSCyqChZ9czJHZQrWZXVlHO1kSQ2JdHqTpskMgGRFdcVO0BXhD2U8MG jQtlxkTBQF9UWcu4CYbXQwkIndUK7cTxB0KIIVonARnFnJ1W91+3DhmX90DEHAa9Gj9DOOwCh37 2R+f9SY6jGMzlRuE4JeN9qNXkEyJf4QGgstJZQVqIK7ALFgN0IUwW/1wcYZf1A1s93OnX0B3xmR gP/a5DkAlus6ZSxru9VQtOBL4cn+BzUKsw7y80XEakf6R4Q7RVuwubdY0xFgMGAJDaFgTAggtZL WjNNqG9lgFMYGq+TwtCPJU6uOUDPQ+ZEzLZRklmqMdtVBAxRpPoAcs4FTvg4lGKEXQH3ylLSz8U T/eZsmN6QuUgt/dzUwXEmapAua/93oGKSBwAi5Rk5AY3TrXfQmWpslle31ENwDj5fuaXL7t24wV wjtMc/rRDyyVdu0DqRsUaTe5X+apCnoE+ndLIV8n65q3E7ut4qSiztNee30dXZiqWTwszonDNUT 9bat5QTr96veRix+HalBdcLx1WhsVsUiiXKGkephbcw9RUUig==
X-Received: by 2002:a7b:cbd3:0:b0:493:cefc:d113 with SMTP id 5b1f17b1804b1-4998794c02emr265452825e9.5.1786978050166; Mon, 17 Aug 2026 07:47:30 -0700 (PDT)
Received: from smtpclient.apple (host-92-23-29-35.as13285.net. [92.23.29.35]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4999cfcee58sm42245595e9.0.2026.08.17.07.47.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2026 07:47:29 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
From: Christopher Dearlove <christopher.dearlove@gmail.com>
In-Reply-To: <BNZP110MB244706588DE323EB450AF3A1A3A7A@BNZP110MB2447.NAMP110.PROD.OUTLOOK.COM>
Date: Mon, 17 Aug 2026 15:47:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CFA824C4-33AC-4D50-879B-4682A25FF64D@gmail.com>
References: <C1CCDB96-0CA4-4409-A704-694A58A0830E@gmail.com> <BNZP110MB244706588DE323EB450AF3A1A3A7A@BNZP110MB2447.NAMP110.PROD.OUTLOOK.COM>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.3864.600.51.1.1)
Message-ID-Hash: I4RFOZ6CN34UV5UGSL37TOMEJSONDXJN
X-Message-ID-Hash: I4RFOZ6CN34UV5UGSL37TOMEJSONDXJN
X-MailFrom: christopher.dearlove@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-manet.ietf.org-0; header-match-manet.ietf.org-1; header-match-manet.ietf.org-2; header-match-manet.ietf.org-3; header-match-manet.ietf.org-4; header-match-manet.ietf.org-5; header-match-manet.ietf.org-6; header-match-manet.ietf.org-7; header-match-manet.ietf.org-8; header-match-manet.ietf.org-9; header-match-manet.ietf.org-10; header-match-manet.ietf.org-11; header-match-manet.ietf.org-12; header-match-manet.ietf.org-13; header-match-manet.ietf.org-14; header-match-manet.ietf.org-15; header-match-manet.ietf.org-16; header-match-manet.ietf.org-17; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "manet@ietf.org" <manet@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [manet] Re: draft-ietf-manet-inet-gap-analysis-06.txt
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/PriOYgYJ3PUUXL-ZGZYNjd7-Y8k>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Owner: <mailto:manet-owner@ietf.org>
List-Post: <mailto:manet@ietf.org>
List-Subscribe: <mailto:manet-join@ietf.org>
List-Unsubscribe: <mailto:manet-leave@ietf.org>
> On 17 Aug 2026, at 15:37, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote: > > Christopher, a cellphone that connects 0 other nodes is still regarded as a MANET (border) router and a singleton MANET unto itself. The point about MANET access control therefore becomes irrelevant. If you choose to consider that degenerate case as a MANET, sure, there’ no access control in that case. Which says nothing about the general case. > All cellphones are MANET (border) routers making the mobile Internet a "MANET-of-MANETs". Scaling is on the order of the number of cellphones that opt into the service, which may eventually include all of them. Relying on preregistration and real time access to a database (or equivalent) of those possible participants. Not the case usually considered as a MANET. > Thank you - Fred > >> -----Original Message----- >> From: Christopher Dearlove <christopher.dearlove@gmail.com> >> Sent: Saturday, August 15, 2026 10:40 AM >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com> >> Cc: manet@ietf.org >> Subject: [EXTERNAL] Re: draft-ietf-manet-inet-gap-analysis-06.txt >> >> EXT email: be mindful of links/attachments. >> >> >> >> (Phone has turned my following comments into as if a quote. Sorry about that.) >> >>> Of course they are connected. I’ve explained why, you’re just asserting that they aren’t. It’s all about access - who is allowed and how to >> implement that. And that affects the scale of the problem. There might be a few networks that allow free for all, relying on limited numbers in >> the geographical vicinity. But for the sorts of MANETs my former employer would have been interested in, that would not be the case. >>> >>> But as I said last time before planning to leave this, I leave it to the WG to have its view on this. >>> >>>> On 15 Aug 2026, at 16:26, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote: >>>> Christopher, while I agree with you that lower-layer security for MANETs is a SHOULD, that point has no relevance to scale in terms of >> numbers of nodes and the two subjects are not connected in any way. Every cellphone is a potential MANET router and can therefore be >> considered as a MANET unto itself (along with any of its personal devices). >>>> Fred >>>>> -----Original Message----- >>>>> From: Christopher Dearlove <christopher.dearlove@gmail.com> >>>>> Sent: Friday, August 14, 2026 3:19 PM >>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com> >>>>> Cc: Templin (US), Fred L <Fred.L.Templin@boeing.com>; internet-drafts@ietf.org; manet@ietf.org; i-d-announce@ietf.org >>>>> Subject: Re: draft-ietf-manet-inet-gap-analysis-06.txt >>>>> Well, it’s up to the WG to decide whether this line - which suggests that talk of a billion possible devices isn’t that useful - should be >> included >>>>> or not. They have both of our comments. >>>>>>> On 14 Aug 2026, at 16:31, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote: >>>>>> Christopher, I am going to abandon this line of discussion: >>>>>>>> Authorization and key management are a red herring in this discussion. >>>>>> A MANET is not the same thing as a WiFi SSID as the integrity of the MANET routing information base needs to be assured. So, lower- >> layer >>>>> security for (multi-hop) MANETs is more critical than for (single-hop) WiFi SSIDs. Just the same, people can and do operate MANETs with >> no >>>>> lower-layer security but that may be risky out in open networks outside of controlled environments. >>>>>> Thank you - Fred >>>>>>> -----Original Message----- >>>>>>> From: Templin (US), Fred L <Fred.L.Templin=40boeing.com@dmarc.ietf.org> >>>>>>> Sent: Friday, August 14, 2026 7:22 AM >>>>>>> To: Christopher Dearlove <christopher.dearlove@gmail.com> >>>>>>> Cc: internet-drafts@ietf.org; manet@ietf.org; i-d-announce@ietf.org >>>>>>> Subject: [manet] Re: draft-ietf-manet-inet-gap-analysis-06.txt >>>>>>> Hi Christopher, >>>>>>>> -----Original Message----- >>>>>>>> From: Christopher Dearlove <christopher.dearlove@gmail.com> >>>>>>>> Sent: Thursday, August 13, 2026 4:19 PM >>>>>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com> >>>>>>>> Cc: internet-drafts@ietf.org; manet@ietf.org; i-d-announce@ietf.org >>>>>>>> Subject: Re: draft-ietf-manet-inet-gap-analysis-06.txt >>>>>>>>>> On 13 Aug 2026, at 22:55, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote: >>>>>>>>>> Hi Christoper, >>>>>>>>>> I appreciate these comments and take it as input that the draft should strive for better balance when talking about numbers. The >>>>> intention >>>>>>>> is not to predict a doomsday scenario where one day all worldwide wireless infrastructure collapses leaving people's cellphones to >> fend >>>>> for >>>>>>>> themselves. Yet, anyone's cellphone can at any time find itself operating outside of cellular coverage and if there are others nearby it >>>>> should >>>>>>>> be capable of forming a MANET. >>>>>>>> Something I meant to note but didn’t i that LTE was developing a mobile to mobile interface. The interest was from emergency >> services. I >>>>>>>> don’t know if it was standardised, or even if it was if implemented. If that went more than one hop you have a MANET. But that would >>>>> most >>>>>>>> obviously grow from a point attached the main network (which might not be the internet). Whether a pure peer to peer network with >> no >>>>>>>> attachment was considered I don’t know. And in any case, this come under the heading of pre-authorised devices. >>>>>>> LTE called it "proximity services" (ProSe) which was the pre-cursor to 5G "SideLink" which 3GPP is currently writing into the standards. >>>>>>>>> Yes, this might require asking someone for the shared secret key, but the technology to support the operating mode should be >> attainable. >>>>>>>> As soon as you say hared secret key, you’ve limited the size of your group of potential members drastically. And have to think about >> how >>>>> to >>>>>>>> hare it. It’s been said encryption I say, key management is hard. (OK, here we’re talking authentication not encryption - though that is >> a >>>>> next >>>>>>>> step - but same principle.) >>>>>>> Authorization and key management are a red herring in this discussion. Not all MANETs will have a centralized administrative authority >>>>>>> responsible for handing out keys; many will be truly open access just as many WiFi SSIDs do not require a password. My Android phone >> lets >>>>>>> me turn off security on my WiFi hotspot. >>>>>>>>> For this reason, I think the draft could be improved by regarding all cellphones as *potential* MANET routers. Whether many or >> even >>>>> any >>>>>>>> ever become *functional* MANET routers is besides the point and not relevant to the fact that they could support the operating mode >> if >>>>>>>> programmed to do so. >>>>>>>> I’m not sure that’ the point. Erything is a potential MANET node if Android and Apple implement it. >>>>>>> Cellphones have both 5G (soon to support SideLink) and WiFi (already supports mesh/IBSS) which are both excellent candidate MANET >>>>>>> Interface types. The hardware underpinnings for a potential MANET router are already in place in modern cellphones, and should >>>>> therefore >>>>>>> be noted as such. >>>>>>>>> Not all that long ago, not too many people imagined that one day a cellphone could act as a WiFi hotspot but in modern times that >>>>> function >>>>>>>> is widely deployed and used all the time. I am not saying with certainty that there will come a day that all cellphones become MANET >>>>>>> routers, >>>>>>>> but the *potential* is already present in devices anyone can buy off the shelf at least from the hardware perspective. >>>>>>>> But while I use the tethering feature of ny phone a lot (right now in fact) only devices I have specifically authoried to ue that hotpot >> can do >>>>>>> so. >>>>>>>> And right now that is two devices (except one is failing to connect). >>>>>>> The password could be removed if you wanted to allow open access to your cellphone's SSID just as many more traditional WiFi >> hotspots >>>>>>> support open access SSIDs. Access authentication is a red herring in this discussion. >>>>>>> I will make a deal with you - as soon as everyone stops using their phones as WiFi hotspots I will stop saying cellphones are potential >>>>> MANET >>>>>>> routers. >>>>>>> Thank you - Fred >>>>>>>>> Thank you - Fred >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Christopher Dearlove <christopher.dearlove@gmail.com> >>>>>>>>>> Sent: Thursday, August 13, 2026 12:39 PM >>>>>>>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com> >>>>>>>>>> Cc: internet-drafts@ietf.org; manet@ietf.org; i-d-announce@ietf.org >>>>>>>>>> Subject: draft-ietf-manet-inet-gap-analysis-06.txt >>>>>>>>>> I haven’t made this comment before, but have been thinking about it. >>>>>>>>>> I am not convinced that the suggestion that there are billions of devices that might connect to a MANET is helpful. >>>>>>>>>> There are billions of phones out there. But for various reasons the architecture used is not a MANET. An important reason why is >>>>> access >>>>>>>>>> control. When you attempt to use your mobile phone, the base station you are trying to connect to verifies you are authored to do >> so. >>>>> To >>>>>>>> that >>>>>>>>>> end it (or other parts of the network on its behalf) consults database(s) to determine both that and other information. Of course >> that is >>>>>>>> highly >>>>>>>>>> optimised in various ways, but that’s not important here, the key thing is that your phone is verified (and cryptographic stuff to >> confirm >>>>>>> that >>>>>>>>>> and more is done, again details not important here). >>>>>>>>>> Why? Well, most importantly from the point of view of the operators is so they get paid. Also for various security related reasons. >>>>>>>>>> Now let’s consider a MANET. There are two obvious scenarios here. A small private network and a larger public network. >>>>>>>>>> Let’s start with the small private network. Yes, there might be quite a lot more potential members than actual members at any >> time, >>>>> but >>>>>>>> it’s >>>>>>>>>> still not in the billions range. Typical use case is an emergency services network (or a military network, though we tend not to >> mention >>>>>>> that >>>>>>>> in >>>>>>>>>> RFCs). We have RFC 7183 whose purpose is to manage access to an OLSRv2 network. The specific methods in there assume a >> shared >>>>>>>> secret >>>>>>>>>> key, although there is an alternative in RFC 7859, but both involve some sort of key distribution to all potential participants. That is >> hard >>>>>>>>>> enough at the hundreds or thousands level. >>>>>>>>>> Or there’s a network with public access. The likely equivalent to that is the Wi-Fi networks we find everywhere. Where typically we >>>>> learn >>>>>>> a >>>>>>>>>> key from a written instruction in our coffee shop or hotel. Or - popular on trains - there’ an authentication process that involves >> email >>>>>>>>>> addresses and network access. That’s not going help us, we will usually need security at a lower level and sooner. And doe this have >> to >>>>> be >>>>>>>>>> free? >>>>>>>>>> (I would be interested to know how the Freifunk network works here. Its it a third case? Or a variant of one of these?) >>>>>>>>>> Of course in the latter case billions is not irrelevant, but mostly because what it says is pre-existing addresses are unplanned and >> non- >>>>>>>>>> aggregatable. That happens well before billions. Unless new addresses are issued. But we still have the problem of how (assuming >>>>>>>> completely >>>>>>>>>> unsecured networks are not allowed in most cases and/or that someone wants to be paid) of how some sort of identity or key >>>>>>> information >>>>>>>> is >>>>>>>>>> to be distributed. For the small private network where billions of users is not relevant, OK. For a network with internet access, >> maybe >>>>> OK. >>>>>>>> For >>>>>>>>>> an isolated MANET as often assumed, not so OK. >>>>>>>>>> My point is that rising the billions of users without addressing these issues - at least making them problems - is likely to lead to >>>>>>> discussions >>>>>>>> of >>>>>>>>>> the form above (or better ones) and hinder any progress of the draft. >>>>>>> _______________________________________________ >>>>>>> manet mailing list -- manet@ietf.org >>>>>>> To unsubscribe send an email to manet-leave@ietf.org >
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Christopher Dearlove
- [manet] I-D Action: draft-ietf-manet-inet-gap-ana… internet-drafts
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Templin (US), Fred L
- [manet] Re: I-D Action: draft-ietf-manet-inet-gap… Templin (US), Fred L
- [manet] Issue tracker (RE: I-D Action: draft-ietf… Templin (US), Fred L
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Christopher Dearlove
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Templin (US), Fred L
- [manet] draft-ietf-manet-inet-gap-analysis-06.txt Christopher Dearlove
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Templin (US), Fred L
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Christopher Dearlove
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Templin (US), Fred L
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Templin (US), Fred L
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Christopher Dearlove
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Templin (US), Fred L
- [manet] Re: draft-ietf-manet-inet-gap-analysis-06… Abdussalam Baryun
- [manet] Re: I-D Action: draft-ietf-manet-inet-gap… Abdussalam Baryun
- [manet] L2/L3 MANETs (Re: Re: I-D Action: draft-i… Templin (US), Fred L
- [manet] Re: L2/L3 MANETs (Re: Re: I-D Action: dra… Abdussalam Baryun
- [manet] Re: L2/L3 MANETs (Re: Re: I-D Action: dra… Templin (US), Fred L