[ntp:hackers] Running out of Recvbufs

Terje Mathisen terje.mathisen at hda.hydro.com
Sun Dec 4 12:00:37 PST 2005


David L. Mills wrote:

> Terje,
> 
> Remember the fuzzball? Fastest gun on the planent 25 years ago.

I'm old enough, but I had no idea where my packets went in those days.

> Configured as a gateway it handled 300 packets per second when its
> nearest competitor redlined at 10 packets per second. For a recent paper
> I calculated redline for a modern NTP server with modest processor at
> over 50,000 packets per second. Obviously, 40 packets in arrears of

That is still 50,000 clock cycles on a 2.5 GHz machine, i.e. orders of
magnitude slower than a really optimal (dedicated) implementation. :-)

OTOH, 50 K packets at about 90 bytes each (or ~800 bits including
preamble/postamble overhead) corresponds to something like 40
Mbits/second, both in & out, which is pretty good on a regular 100
Mbit/s full duplex Fast Ethernet LAN.

> processing represents not a quirk in arrival rate but a failure
> somewhere along the pipeline.

Exactly!

I've taken a much closer look at the source code now, and it would
definitely be possible to make a fast path through it, to handle the
high-volume case of a client request with no authentication and no
restrict limitations.

I.e. effectively doing just these parts of ntp_proto:

/* 	get_systime(&xmt_ts); Do once, upfront!
/*  if (fast_path) { */
	xpkt.li_vn_mode = PKT_LI_VN_MODE(sys_leap,
		    PKT_VERSION(rpkt->li_vn_mode), xmode);
	xpkt.stratum = STRATUM_TO_PKT(sys_stratum);
	xpkt.refid = sys_refid;
	xpkt.ppoll = rpkt->ppoll;
	xpkt.precision = sys_precision;
	xpkt.rootdelay = HTONS_FP(DTOFP(sys_rootdelay));
	xpkt.rootdispersion =
	    HTONS_FP(DTOUFP(sys_rootdispersion));
	HTONL_FP(&sys_reftime, &xpkt.reftime);
	xpkt.org = rpkt->xmt;
	HTONL_FP(&rbufp->recv_time, &xpkt.rec);
	sendlen = LEN_PKT_NOMAC;
	HTONL_FP(&xmt_ts, &xpkt.xmt);
	sendpkt(&rbufp->recv_srcadr, rbufp->dstadr, 0, &xpkt,
		    sendlen);

OTOH, this would also slightly slowdown all other paths, including all
the crypto stuff.

I am also worried about how much of the DoS stuff is really needed
before such a hack.

What would have been a _really_ neat hack would have been to maintain a
properly configured reply packet at all times, i.e. updating the
li_vn_mode, stratum, refid, ppoll, precision, rootdelay and
rootdispersion fields in network byte order each time they are updated,
and allowing the reply to be sent immediately. :-)

Terje

-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
-------------- next part --------------


***********************************************************************
NOTICE: This e-mail transmission, and any documents, files or previous
e-mail messages attached to it, may contain confidential or privileged
information. If you are not the intended recipient, or a person
responsible for delivering it to the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of
any of the information contained in or attached to this message is
STRICTLY PROHIBITED. If you have received this transmission in error,
please immediately notify the sender and delete the e-mail and attached
documents. Thank you.
***********************************************************************



More information about the hackers mailing list