[Proposal] WiMNC (Multiple MNC Discovery)

[zenith391]

Proposal

What is it

WiMNC would be a just very simple addition to how GERTi MNC works. It's made to be very simple, but also useful to RP servers, OC tablets, wireless GERT communication, etc.
Please note that as WiMNC is made for wireless communication, it doesn't respect clause B of GERTi Backend, therefore it should be optional.
WiMNC allows the user to select what MNC server to connect to, and also adds a protection layer compared to the actual connection method, however it can removes the automatic connection feature so the best would be that if GERTi API isn't provided arguments at import (maybe using dofile), it would keep the original connection mechanism, else it would use WiMNC, or allow the OS to manage it, for user interactivity, for example on openos a wimnc command

Basic information

A WiMNC broadcast is sent every 10 seconds containing information about the MNC. This feature IS optional (as it is not applicable for wired networks)

Communication

When broadcastings are sent through default OC modem port 32594.

Specifications

All packets are sent through port 32594!

WiMNC broadcast packet

The packet format is: a String containing the component ID of modem (for connection), a String containing the name of the WiMNC (can be anything, may default to "WiMNC Broadcast"), and a String containing the protection method (see below for values)

Protection methods

This proposal only specifies one protection methods and leaves the rest to the GERT maintainers. The method of encryption is not defined. The client authenticates using a password by sending a password validation packet. If after 1 second the server doesn't respond, the client will abort the authentication. This proposal also specifies an "unprotected" mechanism which requires no authentication.

Password validation packet

The password validation packet is just a string containing the SHA256 of password. As it is used for validation, the hash SHOULD NOT be used as key for encryption, so that since a hash is almost impossible to reverse-engineer, it would be secure.
The WiMNC-capable MNC will respond by a packet containing a boolean. True if password is correct, False if password is uncorrect.

[TYKUHN2]

Edited for brevity and clarity

[TYKUHN2]

As a side note, common real-world protection schemes use hashed passwords for encryption keys (using functions known as PBKDF.)

[zenith391]

Ok. But if you plan on doing so when thinking about protection methods, use a different hash than SHA-256

[MajorGeneralRelativity]

It's definitely an interesting idea. I raised a concern on the Discord about this, but I'm willing to seriously consider this.

[zenith391]

Also i forgot to said it since all time, but the whole point of having multiple MNC is that wireless range is limited, and doing cables require chunk-loading all of them (unless there is a specific mod for it, which is to avoid)

[MajorGeneralRelativity]

Multiple clients can broadcast a wireless signal. You don't need more than one MNC for that.

[zenith391]

You mean clients can like, "extend" the wireless range of MNC by relaying its packets?

[MajorGeneralRelativity]

Because GERTi is partially a mesh network, not all packets run through the MNC. Clients can join the network by connecting to other clients, which can then act as a relay. In one sense, they do act as wireless extenders, but I just want to try to clarify that the MNC is not directly involved with all internal network traffic.

[zenith391]

Oh, i didn't knew that. Well, except for security, WiMNC is useless. And that's cool that clients can act as relays.

[zenith391]

But like i said, you could maybe implement some sort of security layer between clients and MNC. Because for now, if a client act as relays, it can easily read messages originally sended to an other client. And even do spoofing (sending messages as it)

[zenith391]

Anyways i'm closing this issue, we can continue to speak here if it's about the security layer

[MajorGeneralRelativity]

I totally understand what you are saying about security. I tried to implement some limited controls in the base protocol, but there is only so much I can do in the amount of space I wanted to use. I feel that it would be best for a security protocol to sit above GERT and perhaps expose wrapped sockets. That way, it doesn't increase the size of the GERT protocol and can remain optional due to not everyone needing the extra security.

[zenith391]

Yea, i think a library including some sort of security would be the most appropriate