In message <58112F9F.6060705@vaxination.ca>, Jean-Francois Mezei <jfmezei_nanog@vaxination.ca> wrote:
A camera showing the baby in 4K resolution along witgh sounds of him crying on dolby surround to the mother who is at work would likely saturate upload just as much as the virus sending DNS requests. This falls into the tonne of feathers weighting as much as a tonne of lead category.
Agreed. So the "solution" is either to define such devices out of the problem set (i.e. to say "that is not really an IoT type device") or else to find some other solution. Questions: Does the 4K baby monitor (or the 4K 7-11 parking lot cam) need to be sending its high-bandwidth outbound feed, arbitrarily, to absolutely anything? Could it instead reasonably be limited to sending its high- bitrate data _only_ back to just those clients which themselves had first made an inbound TCP connection to the thing? (Note: The video data itself wouldn't necessarily have to travel back to the client via the TCP session. It could be sent back to the client via a separate and parallel UDP data link directed back to the same IP that initiated, and that is currently holding open the TCP session. I think that this is kinda/sorta how FTP works, actually.) IoT devices that need to send a *lot* of data out can be programmed to only send such high-rate/high-bulk data to client IP addresses that currently have live TCP sessions open... ones which the clients them- selves initiated... and the kernel can be made to enforce this simple restriction. Problem solved. No DDoSing of arbitrary IP addreses here! Move along. Alternatively, in the model where the security camera needs, for whatever reason, silly or otherwise... to be the one that initiates an outbound connection (and then just blasts its data up through that) it seems to me that it should not be too awfully hard to minimally enforce, in the kernel, just step 1 of a kind of SMTP-ish protocol... one where the IoT device initiates the outbound connection, to an IP address of its choosing (perhaps after having done a DNS lookup to find it) and where the IoT device then does nothing unless and until it gets some kind of affirmative signal from the other side... like a 2xx banner/greeting which effectively says to the IoT device "I'm here, and you are Clear-To-Send." (Again, it isn't necessary for the IoT device to send the actual data stream up through this TCP connection. It could be sent via UDP, but only to the pre-verified "cloud" IP address that we have already established is willing to accept the bulk data.) Of course, it would be best if there were some sort of a standardized port number and protocol for this specific kind of IoT-to-Cloud interaction. It would surely cause problems to try to overload these semantics on top of, say, port 25. So, in summary, it isn't even necessary to define video cameras out of the "IoT" problem set. The problem is excessive outbound data flowing to perfectly arbitrary "victim" IP addresses. (And remember, even attack reflectors are victims too.) Given the problem statement, the solution is obvious: You gotta start building boxes that have kernel-enforced restrictions that fit one or the other of these two models: 1) Ordinary (non-cloud-oriented) things MUST either: 1a) be prevented from sending large amounts of data outbound AT ALL, ever, or else 1b) be prevented from send large amounts of data outbound *except* when explicitly requested to do so by some verified IP address... which is to say an IP address that has initiated and completed an inbound TCP handshake 2) Cloud-Oriented things MUST be prevented from sending "unsolicited" bulk data to any IP address other than one which has very explicitly consented to receive it, i.e. by accepting and completing an inbound TCP handshake on some specially reserved port, and perhaps also via some additional layered trivial RTS/CTS protocol. That's it. Simple, no? Implementation is of course, completely trivial, just as it is for all things that I myself don't actually have to write the code for. Regards, rfg