North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Kiss-o'-death packets?

  • From: Valdis.Kletnieks
  • Date: Mon Oct 06 03:13:39 2003 
On Mon, 06 Oct 2003 02:11:22 EDT, Sean Donelan said:

>   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.

ntp-2.vt.edu used to be an alias for my workstation, until it got moved to a
more production machine.  Two years later, there was still a flux of 50 packets/
 second from machines that thought that even though it had been unreachable
for 2 years(*), maybe THIS time it would answer. (when the
xntpd exploit came out a few years ago, we turned on logging on our border
routers - inside of an hour we had trapped packets from some 6-8 hosts that
were heading to an IP address that hadn't been an NTP server for over 8 years).

The only reason this number is notable is because even when it was a production
server, the packet flux was only 100-150 packets/second.  So obviously, we
can't trust users to get it right.

The problem with a 'kiss-o-death' packet is that it needs to be authenticated.
Otherwise, you can use spoofed packets to DoS somebody.  How many lines are in
your root-DNS hints?  And even if we insist on the KoD packet having the query
ID in it, that's a TINY address space.  I can even feed you spam to force you
to hit the DNS, trickle you some forged KoD packets, and within a day or so
make you refuse to talk to any of the root nameservers... (Note that TCP
connections are a lot more easily dealt with, as the 3-packet handshake adds a
lot to the security.  However, Wesel's numbers on "98% of the root DNS traffic
is bogus" indicate that we really need this on the UDP side of the fence as
well....)

It's the same basic reason why the UCITA provisions for remote deactivation
of software went over like a lead balloon.....

(*) I originally Did The Right Thing and had ICMP Port Unreachables going back,
but some lameware Windows set-your-clock program interpreted those as "Ask
again and maybe it will answer", so it would ask about 50 times a seconds..
continuously (oddly enough, it *didnt* retransmit if it got NO answer). The 5th
or 6th time some bozo installed this program in a lab of 40-80 machines, I gave
up and filtered all responses.

Attachment: pgp00008.pgp
Description: PGP signature