[manet] Re: draft-ietf-manet-inet-gap-analysis-06.txt

> On 13 Aug 2026, at 22:55, Templin (US), Fred L <[email protected]> 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.

> 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.)

> 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.

> 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).

> Thank you - Fred
> 
>> -----Original Message-----
>> From: Christopher Dearlove <[email protected]>
>> Sent: Thursday, August 13, 2026 12:39 PM
>> To: Templin (US), Fred L <[email protected]>
>> Cc: [email protected]; [email protected]; [email protected]
>> 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 -- [email protected]
To unsubscribe send an email to [email protected]