On Thu, Jan 16, 2014 at 10:48 AM, Christopher Morrow < morrowc.lists@gmail.com> wrote:
On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan <asullivan@dyn.com> wrote:
On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote:
So... what other options are there to solve the larger problem of:
"Some service is running on a public host, and it can be used to attack a third party"
where in all of these cases the third party is someone who's address has been spoofed in the src-address of a packet.
Standardizing some UDP service-neutral PRE-Authentication system comes to mind; operating at the host level, independent of the various services, requiring the client to perform at least as much work as the response packet. E.g. Fwknop Single-Packet Authentication/Port-Knocking Style "The application doesn't see any UDP packets from a source:port number pair, until a source address authenticity event occurs, for that source ip:port number pair." Say instead of "port knocking" though, the client is required to estimate the size of the response to its first round trip of UDP request messages. Then the client's UDP stack must construct and send a Hashcash proof of work, of sufficient difficulty based on the estimated query plus response size, up to the first full round trip; containing a message digest of the first UDP packet the client will send, before sending the packet, or it will be silently discarded. An out-of-band reply will come back to the claimed source, that the client souce IP:Port has to acknowledge within 5 packets. Once the out-of-band reply is acknowledged, the source is confirmed not to be spoofed. UDP response packets and new queries above the estimated initial reply size or after the 5th packet are delayed until definitive confirmation or silently dropped, instead of returned to the claimed source. -chris
--
-JH