nic_bridge: Support static IP address configuration

[parthy]

If I am not mistaken, clients of the nic_bridge Nic session have to use DHCP for obtaining an address in order for the communication to work. This means there has to be a DHCP server in the setup. Is that correct?

If so, it would be a desirable feature to support static IP configuration as well.

[iloskutov]

I have done static IP support for nic_bridge, if you interesting I can prepare patch. I need clean up my code first.

[iloskutov]

I have added support static IP address configuration for nic_bridge and libc_lwip_nic_dhcp. my commits: https://github.com/Ksys-labs/genode/commit/2693116c1d39882d25f5274674741faf757305b6, https://github.com/Ksys-labs/genode/commit/2ee81fcbd8a2b1d19cc89b599d50b011b6de7b8f, https://github.com/Ksys-labs/genode/commit/cdf787445dd0545c9db8fa2427f0f5033c3bd389

[parthy]

Thanks for that, I will look into it, when I need it again. A cool improvement would be to do this dynamically. So if the client decides to set its IP address to an unknown value, nic_bridge should build the mapping on demand. The motivation to do this is to allow guest operating systems in a virtualized environment to set their IP address dynamically. What would you think?

[chelmuth]

Doesn't this always end up in ultimate knowledge which network configuration the guest will choose? Then, we would not need a real dynamic solution. IMO dynamic network configuration should be achieved by the Dynamic Host Configuration Protocol (DHCP).

[parthy]

Yes, in the end the guest could only choose an address which matches the surroundings. In that sense, it is no immediate problem to do it statically configured. I see one minor downsides of this, though:

You have to maintain the information in at least two places: the configuration of nic_bridge and the guest, e.g., an init script or even set the IP address by hand everytime. But I understand your point that this resembles a "partly dynamic" system.

[udosteinberg]

Can't the NIC bridge simply snoop MAC addresses like a layer-2 switch does in order to figure out where packets need to go? That would also enable advanced use cases such as a migrating VM sending a gratuitous ARP to notify the bridge that it is now located elsewhere.

[chelmuth]

Nic bridge currently implements proxy ARP to prevent switching the NIC into promiscuous mode. I'm not certain if this is compatible with your mentioned goal as @skalk is the original author of the bridge.

[skalk]

sorry for my late response, I was on vacation.

If I only snoop MAC addresses, I have to forward all ARP requests to all clients, because I don't know their IP address anymore. But how to decide which client response is valid? Without some control from the nic_bridge every client can simply hijack existing TCP/IP connections from another client, whenever some ARP request from the outside arrives. The nic_bridge currently acts as a trusted NIC multiplexer.

[udosteinberg]

You are correct - ARP is sent as a broadcast to all. And yes, spoofed ARP packets could be used to hijack packets - also in real Ethernet. But a switch (or the NIC bridge) is also able to detect if a client tries to move a MAC address from one port to another. You could then classify this as an attack or as a legitimate migration, e.g. depending on policy and/or session information, and act accordingly.

[skalk]

Yes, you're right. ARP spoofing can be done on the physical LAN too. Obviously the nic_bridge isn't able to prevent spoofing of some external Ethernet switch. But it implements some sort of ARP spoof prevention by handling incoming ARP packets on behalf of its clients. Detecting ARP spoof attacks without snooping DHCP packets doesn't seem to be easy to me. To me it is unclear how to obtain the valid relation of MAC/IP addresses without the ability of DHCP snooping. Maybe you know of a special algorithm I'm unaware of? Nevertheless, I'd like to keep the state machine, and implementation of the nic_bridge as simple as possible. By now, Ivan's proposal to use additional configuration values for static IPs in the nic_bridge seems feasible to me. Moreover, when combining that approach with the "reconfiguration ability" introduced in release 12.05:

http://genode.org/documentation/release-notes/12.05#System_reconfiguration_at_runtime

it is possible to change the IP settings at run time, e.g. for VM migration purposes.

[udosteinberg]

My suggestion is to track the MAC address(es) for each client on the NIC bridge. When you see the first outbound packet of a client, you'll know what its MAC address is. Most likely it's an ARP reply packet. Then you store that MAC address along with the session information for the client. Later, when some other client attempts to spoof the MAC address, you can detect in the NIC bridge that you've already learned the MAC for some other session. If that other session has not released the MAC (using some side-band session magic to announce a migration or so), then you know that someone is trying to divert packets for that MAC to some other client, and you can shut the other client down. You can also do stuff like pre-announce your MAC, when you open the session to the NIC bridge or something like that for even more robustness. So this tracks the MAC-to-Client mapping. IP isn't relevant for this part.

What you're apparently also trying to do is track the IP-to-MAC mapping, to prevent IP spoofing. For that you can do something similar. I wouldn't suggest snooping DHCP, because that prevents static IP addresses from working. Rather, if the NIC bridge sends/accepts packets to/from clients only based on MAC address, and not based on IP address, an IP conflict could be detected by ARP as well. For an ARP request who-has MAC X, you'd get either multiple responses (from different clients) or you'll get a different response than last time.

Basically the NIC bridge needs to maintain an ARP cache and do some sanity checks on it. Something like

Client1 : MAC1 : IP1
Client2 : MAC2 : IP2
...

of course, preferably indexed by MAC address for fast packet switching.

[skalk]

@udosteinberg thank you for your explanations.

Now I understand our differences with respect to terminology. When talking about ARP spoofing I didn't mean the client using the MAC of another client. In general, this is no problem at all in the nic_bridge. The nic_bridge is implementing Genode's NIC session interface. This interface includes that the client asks for its MAC address, like you would read the MAC from a NIC driver.

From my understanding ARP spoofing is about an evil client responding to an ARP request who-has IP X (no RARP request!) with its own MAC, although that IP is actually assigned to someone else. Thereby that client tries to tamper the ARP cache of somebody else, e.g. a switch, or the nic_bridge. When initially knowing the correct assignment of IP to MAC addresses, there is of course no problem to detect such fraud. But without that information, when using static IP addresses, you have no means to distinguish a good from a bad response. Of course, you can take the very first response for each IP address request as the valid one to fill the ARP cache. But obviously an evil client might answer as the first one without responding to ARP requests previously too.

Btw. the nic_bridge is already implementing an ARP cache. Nowadays, the ARP cache is filled successively with the information obtained by DHCP snooping. What Ivan added to it is the possibility to add such cache entries via the configuration file of the bridge. Thereby, static IP addresses can be used on top of it. Without that cache, no packet from the outside could be delivered to a client, because all traffic with the outer world is done using one and the same MAC address (no promiscous mode required). The nic_bridge can only distribute packets on the basis of the destination IP address. That's why it always has to know the IP to client assignment. When forwarding the packet to the client it overwrites the MAC address in its Ethernet header with the one from the client.

I hope this enlightens my point.

[nfeske]

In the meanwhile, I have merged the solution of @iloskutov into master. It works fine for letting arora talk to lighttpd when both are connected via nic_bridge.