Most broadcast request/response protocols scale truely badly.
By a push setup, do you mean a voluntary push, or an involuntary push? A push where the client is designed to simply receive data and use it? It seems like in that case, you still have to worry about a client that gets breached such that it can stop listening to the config servers' commands. Then, it can use those commands as a method to locate, and start attacking the command servers.
With the pull scenarios, are you sure you're not confusing the methodology with the current implementations of it? Clients can be installed with a bootstrapper that allows them to use a much more robust mechanism for determining their configuration than just tftp'ing a file. And having recently written a TFTP server, I know that the protocol (as with DHCP) really has no security. It boils down to white-lists and blacklists in either case.
But you could easily implement a system that bootstraps off of TFTP, and then starts running code that supplies a more robust method of pulling config data. However, you still have the case of a rogue client hardware coming up, and running the tftp in a sandbox, and then decomposing the bootstrap program. You'd be in a situation that's very much like open source, with no obscurity to hide behind, and items like macIds can be spoofed, so a client could be fully spoofed with the right sandbox.
Then, it seems, the tack to take would be that even if a client was running spoofed by a rogue entity, what damage could it do? What are you pushing to it, that it could use to attack other computers or the server?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2006-01-24 01:24 am (UTC)By a push setup, do you mean a voluntary push, or an involuntary push? A push where the client is designed to simply receive data and use it? It seems like in that case, you still have to worry about a client that gets breached such that it can stop listening to the config servers' commands. Then, it can use those commands as a method to locate, and start attacking the command servers.
With the pull scenarios, are you sure you're not confusing the methodology with the current implementations of it? Clients can be installed with a bootstrapper that allows them to use a much more robust mechanism for determining their configuration than just tftp'ing a file. And having recently written a TFTP server, I know that the protocol (as with DHCP) really has no security. It boils down to white-lists and blacklists in either case.
But you could easily implement a system that bootstraps off of TFTP, and then starts running code that supplies a more robust method of pulling config data. However, you still have the case of a rogue client hardware coming up, and running the tftp in a sandbox, and then decomposing the bootstrap program. You'd be in a situation that's very much like open source, with no obscurity to hide behind, and items like macIds can be spoofed, so a client could be fully spoofed with the right sandbox.
Then, it seems, the tack to take would be that even if a client was running spoofed by a rogue entity, what damage could it do? What are you pushing to it, that it could use to attack other computers or the server?