Date: Sat, 22 Jan 2000 03:05:14 -0800 (PST) From: "Dan Seafeldt, AZ.COM System Administrator" <yankee@az.com> To: Don Lewis <gdonl@tsc.tdk.com>, security@FreeBSD.ORG Subject: anti-spoof protocol Message-ID: <Pine.BSF.3.91.1000122023821.13757B-100000@gate.az.com> In-Reply-To: <Pine.BSF.3.91.1000122012833.7170G-100000@gate.az.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Perhaps there would be merit for an RFC to add a message/handshake whereby a host, gateway or firewall which detects an attack would send a 'request authentic packet delivery' message back to the host/network which appears to be doing the attack. If these evil packets were truly spoofed - they did not originate from the actual host mentioned on the source address of the packet, then this special complaint packet would eventually arrive at the gateway which was responsible for receiving packets back to the genuine host that the spoofer claimed to be. When this message arrived for the host, a directly attached gateway meant to deliver it to that genuine host on the same subnet would not deliver it to that host. Instead, the gateway responsible for delivering that message to that host would intercept it and then generate a special key which would be appended to any future packets via that gateway sent to the network that complained. In this way, packets for a time until the credential neogotiated expired between these 2 networks, which arrived at the attacked network containing the source address in question which did not contain the appended key could be obviously be assumed to be forgeries and could/would/should be dropped immediately at the gateway of the network containing the host that was originally attacked. This system could and must be upward compatible. As more gateways might be upgraded to handle this, there would be a greater chance that hosts which supported this new system could send a message back to the spoofed address and get a response from the true network gateway at that address instead of the imposter, invoke a handshake for the key, and of course a resolution to the spoofed source address dilemma by requiring for a period of time packets to have the extra identification mark appended to them. The spoofer, whereever he might be, would not be able to guess or know when or if a key was generated but when this happened ALL of his packets would begin to be dropped by the directly attached gateway responsible for delivering packets the particular host he was attacking because his packets whould not have the mark. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.1000122023821.13757B-100000>