[manet] Re: A partial response to <Re: Review draft-perk ins-manet-aodvv2-05>

> -----Original Message-----
> From: Henning Rogge <[email protected]>
> Sent: Wednesday, July 16, 2025 11:07 PM
> To: Charlie Perkins <[email protected]>
> Cc: Juliusz Chroboczek <[email protected]>; manet <[email protected]>
> Subject: [manet] Re: A partial response to <Re: Review draft-perkins-manet-aodvv2-05>
> 
> On Thu, Jul 17, 2025 at 12:39 AM Charlie Perkins
> <[email protected]> wrote:
> >
> > Hello Juliusz,
> >
> > My days as a Unix systems programmer are distant and pleasant memories.  I was, however, quite involved with implementations of AODV
> 20 years ago.  AODV and AODVv2 place similar demands on the operating system. I reckon that AODVv2 will be equally implementable as
> AODV.
> 
> I remember a few implementations of AODV (v1) when I tried to get a
> running version a couple of years ago... all of them did not work
> because they brought a custom kernel module for "kernel 2.6" (or
> similar) with them... demanding a kernel module is not a viable
> option.

Maybe try eBPF?

Fred

> I also don't think that any simulator implementation counts because
> simulators (e.g. NS3 or Omnet) always take a lot of shortcuts which
> make them incomparable to an implementation for a real OS.
> 
> > Beauty is in the eye of the beholder.  In AODV my favorite solutions fit perfectly with the design of ICMP and the meaning of the word
> "reactive". The same design would work for AODVv2.  Perhaps the [manet] WG considers to disqualify any protocol development that
> depends on such real-time reaction.  At least part of that reaction should properly reside in the kernel.
> >
> > I am not aware of the huge security risk, but if you could provide more details I would be interested to learn.  Maybe we could incorporate
> some discussion about it in Section 14 of the draft.
> 
> The issue is that (at least) 99% good C programmers (myself included)
> don't know how to write a reasonable and safe kernel module acceptable
> by the kernel.org group... and if your module is NOT accepted into the
> kernel it will be outdated and unusable very quickly.
> 
> Inserting code into the kernel into networking is always a big security risk...
> 
> Henning Rogge
> 
> _______________________________________________
> manet mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]