From: Jeff D. <jd...@ka...> - 2002-03-21 02:19:21
|
hav...@gm... said: > this implements 3 new features for uml_switch I like most of this, but I'd like to put it in one piece at a time. So, could you break that patch up into smaller, functionally, separate pieces so I can look at them individually? Jeff |
From: Jeff D. <jd...@ka...> - 2002-03-21 18:48:24
|
hav...@gm... said: > Just remove the "#define TUNTAP" around line 20, this way you lose > tuntap and monitor functionality and can test the learning bridge > part. That doesn't help. I want the patch you sent to be send again in smaller, functionally separate pieces. Jeff |
From: Yon U. <hav...@gm...> - 2002-03-23 03:43:26
|
Hello, On Thu, 21 Mar 2002, Jeff Dike wrote: > hav...@gm... said: > > Just remove the "#define TUNTAP" around line 20, this way you lose > > tuntap and monitor functionality and can test the learning bridge > > part. > > That doesn't help. > > I want the patch you sent to be send again in smaller, functionally separate > pieces. Hmm? Your cpp is at the mechanic? ;-) (yeah, yeah, I should have thought of that, it makes your life easier (or less overloaded at least)) Ok, tuntap functionality depends on the learning bridge changes. So I attach 2 patches. The first one will just add the learning bridge functionality. This means: * Hash table with MAC -> Port mappings (port can be a unix socket or later a tun fd), Ports are identified by a MAC Adress, atm. Send USR1 to print this table. Some helper functions are defined for the management of this hash table. The hashing function is not based on any theory, anyone with a little more clues should check HASH_SIZE (128 entries) and HASH_MOD (11, some random prime). * Function update_src() to update the Hash Table depending on received MAC *Source* address. Avoids overwriting static mac address (the addresses of the interfaces in the guests and later the tun mac address) entries. * Function send_dst() to send the incoming packet to the corresponding port(s) and if needed to the monitor port/connection (which is always NULL in this first patch, so just ignore that 2 lines at the end for now) * Garbage collection on the hash table every GC_INTERVAL (2) seconds. Entries older than GC_EXPIRE (100) seconds are removed. Uses SIGALRM. * Extension of struct connection (should be named struct switch_port) with a function pointer to a send function. This is really only needed for the tun function, but it makes the code cleaner and I saw no point in removing it only for the interim patch. The second patch adds a tuntap port to the switch. This adds: * Some random functions for setting up the tun interface (module loading, nod making, etc) Most functions are just stolen from some (older) version of uml_net (iirc). * function handle_tap() to handle input on the tuntap fd. * changes to main() to: 1) init the tuntap 'connection' and set it up as the monitor 'connection' if we are not running as a hub. 2) Register (add_fd) this tuntap channel and handling of it in the poll checking. You'll need the first patch to apply the second one. It should be easy to add cli switches to enable/disable tun and monitor functionality. I think it could be possible to add a function pointer to struct connection to a handle_input(), this would generalize the code and make it more readable and extensible, and would support more than one tun port (which i think makes sense when you only want to monitor now and then and dont want add another context switch for packets you are not really interested atm. so it could be possible to add a uml_switch_control program that dynamically loads and unloads tun/monitor ports, but I'm not going to write it (atm) so I doubt anyone cares about this ;-) The patches are not functionally separate, as you asked. Sorry, but I dont think it makes sense to make just an interim tuntap-only patch when the code to support tuntap is already there. As I said before, I think hogwash + learning bridge is a nice way to put your UMLs online without firewalling on the host, in fact, you could run the an ipv4-less host (as suggested in the hogwash docu, iirc). HTH, HAND yon |
From: Jeff D. <jd...@ka...> - 2002-03-23 23:13:34
|
hav...@gm... said: > Ok, tuntap functionality depends on the learning bridge changes. So I > attach 2 patches. The first one will just add the learning bridge > functionality. This means: This does make things easier. The excellent explanation you provide here would have sufficed the last time though. Just to make sure I understand this bit: A learning bridge is a real piece of hardware, right? The fact that it has a nice name suggests so, but I'd just like to make sure. And it is a switch with some extra intelligence? From the description of the functionality you added, I'm guessing that such a bridge sits on two separate ethernets (which form a single network, hence this is a bridge and not a gateway or router), passing packets from one to the other as necessary. And it figures out what ethernet a particular MAC is on by sniffing traffic as it goes by. What happens when it gets a packet destined for a MAC that it hasn't seen yet? Drop it or broadcast it? I think the current uml_switch drops it, which doesn't seem right. Jeff |
From: Henrik N. <hn...@ma...> - 2002-03-24 13:30:14
|
Jeff Dike wrote: > A learning bridge is a real piece of hardware, right? The fact that it= has > a nice name suggests so, but I'd just like to make sure. My understanding of things (I haven't encountered the term "learning bridge" before): A ethernet bridge is a piece of hardware that sits between two ethernets where at least one is a broadcast ethernet (i.e. coax, radio or hub). An ethernet bridge by definition learns MAC addresses on each side from the traffic it sees. Only packets not known to be on this side of the bridge is forwarded (i.e. same logics as in packets known to be on the other side or where the location is unknown) A standard ethernet bridge also implements spanning tree to make sure there is no loops in precense of many bridges cross-connecting the ethernets. A switch operates in a similar manner but has much more than 2 ethernets and usualy do not implement spanning tree on the ports. A switch forwards packets only to the port where a packet from the destination MAC address have last been seen, or broadcasts the packet on all ports if the location is unknown. Note that on each port there may be any number of MAC addresses, not just a single one. Many switches can also be sub-divided in different LAN segments or VLAN. There is slightly more to VLAN than this such as taggin etc, but it is slightly outside the scope of this thread. Some bridges or switches allow locking MAC addresses to specific ethernets or ports or (only in case of switches) allow you to lock a port to only one MAC. Some even allow you to turn off the MAC address learning entirely if you know what you are doing. > And it is a switch with some extra intelligence? The ability to lock MAC addresses to specific ports is extra intelligence, not the ability to learn where MAC addresses are. Regards Henrik Nordstr=F6m |
From: Lennert B. <bu...@gn...> - 2002-03-24 13:37:10
|
On Sun, Mar 24, 2002 at 02:26:54PM +0100, Henrik Nordstrom wrote: > A standard ethernet bridge also implements spanning tree to make sure > there is no loops in precense of many bridges cross-connecting the > ethernets. > > A switch operates in a similar manner but has much more than 2 ethernets > and usualy do not implement spanning tree on the ports. Pretty much all commercial switches I've seen do speak STP, though (apart from perhaps some el-cheapo 4-port and 8-port ones). cheers, Lennert |
From: Jeff D. <jd...@ka...> - 2002-03-24 17:42:38
|
hn...@ma... said: > An ethernet bridge by definition learns MAC addresses on each side > from the traffic it sees. Only packets not known to be on this side of > the bridge is forwarded (i.e. same logics as in packets known to be on > the other side or where the location is unknown) > A switch forwards packets only to the port where a packet from the > destination MAC address have last been seen, or broadcasts the packet > on all ports if the location is unknown. Note that on each port there > may be any number of MAC addresses, not just a single one. bu...@gn... said: > Pretty much all commercial switches I've seen do speak STP, though > (apart from perhaps some el-cheapo 4-port and 8-port ones). From this description, it sounds to me like there is no real difference between a bridge and a switch. A bridge sounds like a two-port switch. And where can I read about STP? > Some bridges or switches allow locking MAC addresses to specific > ethernets or ports or (only in case of switches) allow you to lock a > port to only one MAC. Some even allow you to turn off the MAC address > learning entirely if you know what you are doing. Is there a standard command set for doing this sort of thing? Jeff |
From: Lennert B. <bu...@gn...> - 2002-03-24 17:49:47
|
On Sun, Mar 24, 2002 at 12:45:24PM -0500, Jeff Dike wrote: > > Pretty much all commercial switches I've seen do speak STP, though > > (apart from perhaps some el-cheapo 4-port and 8-port ones). > > From this description, it sounds to me like there is no real > difference between a bridge and a switch. A bridge sounds > like a two-port switch. To add to the confusion, the linux bridging implementation handles an arbitrary number of ethernet ports (and the BSDs call it bridging too, so I'm certainly not the one at fault). > And where can I read about STP? linux/net/bridge/br_stp*.c ;-) The standard is called 802.1d, and should be available from: http://standards.ieee802.org/ (look for "Get IEEE 802") > > Some bridges or switches allow locking MAC addresses to specific > > ethernets or ports or (only in case of switches) allow you to lock a > > port to only one MAC. Some even allow you to turn off the MAC address > > learning entirely if you know what you are doing. > > Is there a standard command set for doing this sort of thing? I don't think so. cheers, Lennert |
From: Henrik N. <hn...@ma...> - 2002-03-24 23:19:11
|
Lennert Buytenhek wrote: > To add to the confusion, the linux bridging implementation > handles an arbitrary number of ethernet ports (and the BSDs > call it bridging too, so I'm certainly not the one at fault). It is bridgeing. Even what a switch does between it's ports is bridgeing. The fact that the device is named switch is because its total function isn't a like that of bridge between someting, more like that of switchboard. Regards Henrik |
From: Henrik N. <hn...@ma...> - 2002-03-24 23:19:11
|
Jeff Dike wrote: > From this description, it sounds to me like there is no real difference > between a bridge and a switch. A bridge sounds like a two-port switch. Actually, from evolution it is the other way around. A switch is a multi-port bridge, often with most of the bridgeing implemented in silicon. The extremely simplified history of evolution that lead to the Ethernet switch is somewhat like 1. Broadcast ethernets (coax), with high cost low performance routers between LAN segments when spanning larger areas than an small office. Worked good for a while but as things grows the nework suddenly started collapsing due to reaching the limits of ethernet in length.. (the limit was well known, but often not accounted for when extending the networks with more and more computers). 2. Bridges to improve the performance of large ethernets to avoid the cost, complexity and performance bottlenecks of routers and to greatly simplify networking and especially deployment of netbui and other protocols not really suitable for routing. STP is a key component here allowing a bridge mesh to be easily deployed as needed and for fault tolerance. 3. Twisted pair gradually replacing coax as a more manageable ethernet media, with bridges between ethernet hubs. 4. Multi-port TP "bridges", named "switch" as the name "bridge" do not apply to something that has more than two sides.. also signals the switch of technology from software to silicon for performance. Between 2 and 4 there also evolved a couple of multi-port bridges, but these never really got any hold in the market and were quickly outrun by the high performing ethernet switches found everywhere today. > > Some bridges or switches allow locking MAC addresses to specific > > ethernets or ports or (only in case of switches) allow you to lock a > > port to only one MAC. Some even allow you to turn off the MAC address > > learning entirely if you know what you are doing. > > Is there a standard command set for doing this sort of thing? Not that I know of. As said before it is added intelligence out of the ordinary to have anything in a bridge or switch requiring configuration. Maybe there is some common bits in an SNMP MIB somewhere but probably not. Different vendors who implement capabilities like this also has different capabilities or limitations in these functions. As for "command set" outside of SNMP pretty much every switch, bridge or router family have their own set of confusing commands. Regards Henrik Ps: In UML I am still using the old networking code with it's simple hub daemon as it is more like an ethernet than the current thing and easier to work with for my purposes with it's simple virtual ethernets. |
From: Jeff D. <jd...@ka...> - 2002-04-07 22:01:16
|
hav...@gm... said: > The first one will just add the learning bridge functionality. This > means: The MAC passed in with the connect request is associated with that port and assumed to be static. Does this make any sense? I've changed the connect sequence so that no MAC is passed in. That makes the current notion of a static MAC sort of pointless. That's not to say that there couldn't be an interface for tying one (or more) MACs to a port, but it seems wrong to tie the MAC of the UML that opens the port to the port. Jeff |
From: Yon U. <hav...@gm...> - 2002-04-07 23:18:16
|
Hi, On Sun, 7 Apr 2002, Jeff Dike wrote: > hav...@gm... said: > > The first one will just add the learning bridge functionality. This > > means: > > The MAC passed in with the connect request is associated with that port and > assumed to be static. Does this make any sense? As a security measure. If the hosting provider controls the startup sequence of the UMLs, no MAC spoofing is possible on that uml_switch network. > I've changed the connect sequence so that no MAC is passed in. That > makes the current notion of a static MAC sort of pointless. Yes, it should work nicely with or without static entries. Some kind of ID might be welcome by some users, as a way to identify the ports. The static MAC was taking that function. > That's not to say that there couldn't be an interface for tying one (or more) > MACs to a port, but it seems wrong to tie the MAC of the UML that opens the > port to the port. If the MAC is under control of untrusted users, you have a possibly very entertaining network. I just used the notion of static MACs as I felt it was the right way of mixing learning bridge and the configuration (as it was then) of the UMLs. It avoids the timeout problem (and consequent broadcasting of unicast frames) for those static frames, OTOH ARP will have the same effect (broacast request, unicast answer 'teaches' the timeouted entry). Iff your umls have an arp timeout greater than the learning bridge timeout, then you will get this behaviour (I remember a guy having this problem on a usenet newsgroup with cisco switches. His application would just send simplex (one way, no receiving) UDP packets, and after a while they started getting broadcasted all over the L2 infrastructure.) But this is really not an issue for 100%-epsilon of the use cases. What I would love to see integrated is the monitor port functionality. I think there is market for that feature. Oh, BTW, if i resize the window (xterm) the console is running, I get a funny error (and kernel hang). Apparently WINCH is killing the main thread. TIA, HTH, HAND yon |
From: Henrik N. <hn...@ma...> - 2002-04-08 00:36:50
|
On Monday 08 April 2002 01:11, Yon Uriarte wrote: > It avoids the timeout problem (and consequent broadcasting of > unicast frames) for those static frames, OTOH ARP will have the > same effect (broacast request, unicast answer 'teaches' the > timeouted entry). Iff your umls have an arp timeout greater than > the learning bridge timeout, then you will get this behaviour (I > remember a guy having this problem on a usenet newsgroup with cisco > switches. His application would just send simplex (one way, no > receiving) UDP packets, and after a while they started getting > broadcasted all over the L2 infrastructure.) But this is really not > an issue for 100%-epsilon of the use cases. This problem is only seen in switches/bridges if the receiving station only receive packets and never transmit any. Easily avoided by not timing out MAC entries in the switch and not use static ARP tables on the sending hosts.. or by having the receiving stations sporadically send some packets somewhere.. Usually the ARP revalidations is sufficient to keep the switching table up to date. Regards Henrik |
From: Jeff D. <jd...@ka...> - 2002-04-08 01:40:28
|
hav...@gm... said: > If the MAC is under control of untrusted users, you have a possibly > very entertaining network. I just used the notion of static MACs as I > felt it was the right way of mixing learning bridge and the > configuration (as it was then) of the UMLs. OK, this all makes sense. My initial objection to that was that it only works for those UMLs that are directly connected to the switch and not those which are gatewayed to it somehow. But I guess that whatever those UML are directly connected to is responsible for their security. This seems to interact with the process of handing out MACs, so I would like to defer the security stuff for the moment. I've backed out the change which let the switch hand out MACs. It seemed useful and clever, but some mechanism is going to be needed that works for all the host transports. When that exists, the uml_switch mechanism will be obsolete. So, what I'm currently pondering is a central MAC authority of some kind which hands out MACs and cookies. The switch would have access to the MAC-cookie correspondence and would use that to kill MAC spoofing. The UML would hand over the cookie (but not the MAC necessarily) on the connection, and the switch would look up the MAC for that cookie, and tie it to that port. This central authority could be a dhcpd-like thing (or maybe could actually be dhcpd) or it could be whatever is executing the UMLs, in which case, the cookie would be on the command line somehow (maybe in a file named on the command line rather than actually on it). Does this make sense? Jeff |
From: Henrik N. <hn...@ma...> - 2002-04-08 02:59:53
|
The MAC authority thingy seems like a good idea. But I think it should be an optional component, not a strict requirement. There should at least also be the options override the MAC address from within the UML using ifconfig.. For a start, this MAC authority need not be more than a plain text file, listing the MAC address for each <umid,interface>. The file name can be specified as a command line argument to UML, or via a default compiled path if not specified. Having uml_switch optionally integrate with the MAC authority to automatically set up ethernet firewalling to block MAC spoofing is also a nice idea, but again, it should be optional. If there is ethernet firewalling in uml_switch, then other methods of defining this firewalling should also be allowed, and it must be possible to run without this firewalling. MAC address security should not be addressed within UML but rather in the transport it connects to. Same thing for IP security. From a security perspective MAC based firewalling is no different than IP based firewalling. I don't agree that uml_switch should go away. Userspace networking is very handy when setting up virtual networks only existing between UML stations. If you look into authentication then I would advice that you device an authentication sheme where the UML as such has to authenticate, to guarantee that the umid is not stolen by another user. When a UML connects somewhere, it should identify itself by umid. If needed it should also authenticate using a shared secret guaranteed to only be known by the host administrator and the owner of the UML umid. Shared secrets (i.e. cookies) is useful for authentication, but should be stored in a file only readable by the user owning the secret/cookie. Authentication secrets should not be passed as command line arguments or environment as these can easily be read by other users on the system. Regards Henrik On Monday 08 April 2002 04:43, Jeff Dike wrote: > OK, this all makes sense. My initial objection to that was that it > only works for those UMLs that are directly connected to the switch > and not those which are gatewayed to it somehow. But I guess that > whatever those UML are directly connected to is responsible for > their security. > > This seems to interact with the process of handing out MACs, so I > would like to defer the security stuff for the moment. I've backed > out the change which let the switch hand out MACs. It seemed > useful and clever, but some mechanism is going to be needed that > works for all the host transports. When that exists, the > uml_switch mechanism will be obsolete. > > So, what I'm currently pondering is a central MAC authority of some > kind which hands out MACs and cookies. The switch would have > access to the MAC-cookie correspondence and would use that to kill > MAC spoofing. The UML would hand over the cookie (but not the MAC > necessarily) on the connection, and the switch would look up the > MAC for that cookie, and tie it to that port. > > This central authority could be a dhcpd-like thing (or maybe could > actually be dhcpd) or it could be whatever is executing the UMLs, > in which case, the cookie would be on the command line somehow > (maybe in a file named on the command line rather than actually on > it). > > Does this make sense? > > Jeff > > > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel |
From: Jeff D. <jd...@ka...> - 2002-04-08 01:40:30
|
hav...@gm... said: > Oh, BTW, if i resize the window (xterm) the console is running, I get > a funny error (and kernel hang). Apparently WINCH is killing the main > thread. Cool, fixed. Thanks for letting me know. Jeff |
From: Jeff D. <jd...@ka...> - 2002-04-08 03:19:12
|
I've put most of the learning bridge patch in. I left out the GC for the moment. I played with it some and it seems to be fine. Have a look and let me know what you think. Jeff |
From: Yon U. <hav...@gm...> - 2002-04-08 22:06:10
|
Hi, On Sun, 7 Apr 2002, Jeff Dike wrote: > I've put most of the learning bridge patch in. I left out the GC for the > moment. I played with it some and it seems to be fine. I need the monitor/tun port, so I wont test this code. I've read over it and it seems ok to me. Without GC there is a possibility for a DOS, but that exists anyway (create n entries for n >> 2^32 (possibly quite a few bits more, I dont have the IEEE address plan in my head)). With GC the machine will lose some of the learned mappings in time, but an attacker (untrusted hostee) can generate a few thousand per second anyway, so GC wont be much of a solution. Dropping entries (having a maximum number of entries in the hash) isnt an optimal solution either, but at least uml_switch wont start happily allocating all the host's memory for its MAC table. Remember code red/blue and how it killed some badly programmed network devices cough*cisco*cough. Of course, it could be argued that if you have a class B off your ethernet port you are doing something wrong. > Have a look and let me know what you think. > > Jeff |
From: Michael R. <mc...@sa...> - 2002-04-08 04:22:45
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jeff" == Jeff Dike <jd...@ka...> writes: Jeff> hav...@gm... said: >> The first one will just add the learning bridge functionality. This >> means: Jeff> The MAC passed in with the connect request is associated with that port and Jeff> assumed to be static. Does this make any sense? I've changed the connect Jeff> sequence so that no MAC is passed in. That makes the current notion of a Jeff> static MAC sort of pointless. I'm kind of indifferent as to who assigns the MAC address. However, having uml_switch assign it just seems wrong to me. Further, that pretty much eliminates doing any kind of bridging by a UML (you might even be testing the bridging code!). uml_switch should learn. My main concern is churn to the networking protocol. We use a modified uml_switch (called uml_netjig) to do regression testing. I badly need to refactor stuff so that I can include the relevant stuff instead of editing it. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPLEAl4qHRg3pndX9AQHGAQQAsVON/ZMJD4oiR2vu/ked5pPdKnv2ppRf UVsOyBq59U7RzxRgvtM7iZPWqERqVEIMYVUbPokYm0rNTkhD0jZeuKtAAOy0yZkf flSjOePFiIlaM+AUp/BZI2bMuF2xmPb7Syk+OLVrdMdRRXpI2FgSDaWCEuecQy/3 XTje9aOHjZs= =LOB+ -----END PGP SIGNATURE----- |
From: Jeff D. <jd...@ka...> - 2002-04-09 00:22:26
|
hav...@gm... said: > I need the monitor/tun port, so I wont test this code. I've read over > it and it seems ok to me. OK, good. The GC is next, and then the TUN/TAP connection. I wanted to put it in in pieces so that they could be tested individually. Jeff |
From: Jeff D. <jd...@ka...> - 2002-04-10 20:15:57
|
The latest utilities contains MAC GC and TUN/TAP support. You have to have the tap device already set up, i.e. with tunctl, ifconfig it, set up routes, etc. I left out the TUN/TAP configuration because that would require uml_switch to be run as root, which I'm not very interested in. You invoke it with '-tap tap0' or whatever tap device you set up for it. Jeff |
From: Yon U. <hav...@gm...> - 2002-03-21 17:22:23
|
Hello, On Wed, 20 Mar 2002, Jeff Dike wrote: > hav...@gm... said: > > this implements 3 new features for uml_switch > > I like most of this, but I'd like to put it in one piece at a time. > > So, could you break that patch up into smaller, functionally, separate > pieces so I can look at them individually? Just remove the "#define TUNTAP" around line 20, this way you lose tuntap and monitor functionality and can test the learning bridge part. The monitor support is still in there, but wont get initialized (monitor support is just 2 statements in send_dst() before the last return) Im not sure wethere it supports all of the IEEE MAC address semantics or not. HTH, HAND yon |