nanog mailing list archives

Re: Kiss-o'-death packets?


From: "Paul" <paul () rusko us>
Date: Mon, 6 Oct 2003 02:55:42 -0400


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" <sean () donelan com>
To: <Valdis.Kletnieks () vt edu>
Cc: <nanog () merit edu>
Sent: Monday, October 06, 2003 2:11 AM
Subject: Kiss-o'-death packets?



On Mon, 6 Oct 2003 Valdis.Kletnieks () vt edu 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.



Current thread: