North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Kiss-o'-death packets?
I would agree that for some application protocols this would be useful++. Letting layer 7 generate layer 3 responses though is, imvho, a bad idea (tm) from an architectural perspective. Beyond that, in Linux (and I would imagine a few other OSes) ICMP is in-kernel, which lowers the practicability of implementation right out of the gate. I am sure you probably thought of this, but what happens if I spoof an ICMP Go Away? Keeping things like this within the protocol that takes care of authorization (of transmissions) is a logical choice, I would think. Paul ----- Original Message ----- From: "Sean Donelan" <[email protected]> To: <[email protected]> Cc: <[email protected]> Sent: Monday, October 06, 2003 2:11 AM Subject: Kiss-o'-death packets? > > On Mon, 6 Oct 2003 [email protected] wrote: > > My favorite: > > > > "ntp-1.vt.edu is portscanning me very slowly with source port 123...." > > > > The really sad ones are the ones who 3 days earlier dropped me a note to tell > > me they'll using our NTP server..... > > Due to the propensity of people to configure NTP in various annoying ways, > and then failing to respond to requests to fix their systems, the NTP > developers added a new command packet to the protocol. > > To help reduce the level of spurious network traffic due to obsolete > configuration files, a special control message called the kiss-o'-death > packet has been implemented. If enabled and a packet is denied service > or exceeds the client limits, a compliant server will send this message > to the client. A compliant client will cease further transmission and > send a message to the system log. See the Authentication Options page > for further information. > > Should other protocols include the same feature? If someone sends you > a Dynamic DNS update, could the protocol include a kiss-o'-death packet > to tell clients to go away? If someone keeps probing your HTTP server, > should HTTP include a kiss-o'-death packet to tell clients to go away? > If someone connects to your SMTP server, should SMTP include a > kiss-o'-death packet to tell clients to go away. > > Or is this such a widely needed feature, should we try to include it > in a base protocol such as IP/ICMP? > > In a large number of these cases, its not malicious, its misconfigured. > A host could respond to a connection with an ICMP Go Away packet. Even if > the end-host doesn't comply, an edge device or firewall using ICMP > snooping could detect the Go Away packet and change its configuration. > By pushing the control out to the edges, we avoid overloading the core > with one-to-one configuration changes. Using a four-way handshake, its > possible to protect against most types of spoofing and denial of service > even without encryption or keys distribution. > > If you think the root servers are attacking you, Ok. Send a Go Away > packet, and you won't get any more packets from the root server. Why > would you do this? I don't know, but that's your choice. It would get > the ISP out of the business of deciding what should be considered network > abuse, and what isn't. After the user stops shooting himself in the > foot (or runs out of toes), maybe he'll fix the broken auto-firewall > software which thinks everyone is attacking him. > > At NANOG in Chicago, if anyone would like to discuss it further let > me know. >
|