OpenHarbors - Dynamic Tunneling of WPA over IP/L2TP

[Michael Richardson]

Linus Lüssing <linus.luessing at c0d3.blue> wrote:
    > On Wed, Jun 19, 2024 at 02:32:20PM -0400, Michael Richardson wrote:
    >> Radius already does this, and does it better.  And Radius v1.1 over
    >> TLS is a significantly better protocol than the NAT44 hostile
    >> MD5-authenticated thing of yore.  Take a page from eduroam.

    > I don't think that RADIUS does this, this does not work for us with
    > Freifunk.  Just like we can't offer eduroam on a Freifunk mesh node /
    > AP right now either:

Then I don't really understand what you are trying to accomplish.

    > exchange send the pairwise-master-key to the AP. WPA encryption is
    > between the client/supplicant and the AP/authenticator only. The RADIUS

Yes, so you want to forward packets to some other place with no prior
trust relationship?  Sounds like DDoS attacks will be abundant.

    >> L2TP is a disaster, requires IPsec transport mode to be secure.  Just
    >> don't.

    > If the frames within L2TP are still WPA encrypted then this shouldn't
    > need an extra layer of encryption around it via IPSec?  If this were
    > not secure over the internet then it would not have been secure over
    > the air in the first place either.

1. The L2TP system requires trusted setup.  Typically, there is a layer of
   PPP inside the L2TP, which uses a username/password.  Often very weak.
   Often not encrypted at the PPP layer either.
   L2TP daemons (I used to maintain one) just don't do well on the live
   internet.

2. There are things the access points might want/need to do, so they really
   would be better off being able to send packets.

3. WPA. WPA2. WPA3.  How long has it taken for it to protect against rogue
   de-auth packets?  How will the AP even be able to send them?






--
Michael Richardson <mcr+IETF at sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 515 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20240619/ec1929da/attachment-0001.sig>