Justin Cormack <[EMAIL PROTECTED]> writes: > > 1) Network Address > > There is very little standardization right now, there may never > > be so an implementation should be able to select a mac address, > > and a ip address at compile time. > > > > I would suggest a multicast ip and the corresponding multicast > > mac address be used. As it allows any client on your local network > > to receive the packet. This is flexibility with the switch doing > > the work instead of the client. > > Not everyone has multicast support in their switches, but this is nice, so > you get redundant logging etc.
I would have to check. Multicast has been a part of ethernet for a long time. If it isn't supported directly, it should at least devolve to broadcast. Only implementation experience can really answer this question though. > The only question is whether you want to hard code or have an arp type > interface to get the address. If you dont use multicast, the address is > more likely to change, so you may need a discovery protocol. Broadcast, as > discussed before is not very friendly. I want to hard code. My ideal NIC would not require DMA so I could use it when I am setting up RAM. In which case I have no storage space to store an ARP reply. And given that with multicast, and broadcast there is a general solution that allows everything to be hard coded. Simply allowing someone to hard code something else sounds reasonable. > > 4) Control. > > Using existing network control mechanisms telnet, ssh, etc. Look > > like the right solution in 99% of the cases. For the case of the > > fully trusted network (A cross over cable) I suggest simply > > listening for udp datagrams to any ip, but directly aimed at your > > mac address. > > You probably want to filter by port too, Agreed. Filtering by port to implement channels make sense. Filtering to implement security is pointless. > all sorts of udp packets are > probably flying around if you are not using a dedicated network (you > might have a trusted switched network). The only time that ssh etc tend > to break is when networking breaks, or if you fail to boot. My current > thought though is (if you are using DoC or have space) to always boot off > DoC, and then you can rivot_root onto a disk or whatever if you want to, > so there is a failsafe boot. Some additional thinking. A console implies trusted ``local'' access. Translating this to a network this is a cross over cable between machines. So a network console should be a protocol that is designed to run in the above scenario and is useful in variants of it. With that definition, I can finally put my security fears to rest. When you are actually controlling a machine it is convinient to be able to send a break signal for support of things like sysrq. So I propose using 255 as an escape character. And adapoting a subset of the other telnet escapes. 255 243 Break 255 255 Character 255 And other telnet escapes if we have the need. For me at least the concept seems sound. If you can find them please feel free to poke holes in my thinking. I feel reasonably confident that simple and brain dead implementations can now be used for doing local hacks. Eric
