EditWYSIWYGAttachPrintable
r14 - 2008-06-18 - 06:22:21 - HarlanStennYou are here: NTP >  Dev Web > GoogleSummerOfCode > GSoC2008sntp
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

SNTP (Google Summer Of Code, 2008)

Proposal

We need a new SNTP program.

This program will be a "reference" implementation of SNTP, based on the latest NTPv4 document.

SNTP is first and foremost a lightweight NTP client.

It will use GNU AutoGen (like the rest of the NTP programs) for its options processing.

While an SNTP implementation may talk directly to a reference clock, the core requirement for this effort is to be a simple client implementation.

We have an existing implementation based on an older specification. It contains functionality that is obsolete.

You could write a ground-up implementation or take the existing one and hack it in to shape, or some combination of the two. UPDATE - the existing code can be used for ideas, but it cannot be directly used because it is GPL code.

Requirements: Good C skills

Related Topics: http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-09.txt

Preferred License: ISC or NTP (or equivalent)

Sponsoring Organization: http://www.freebsd.org/projects/ideas/#p-sntp

Mentor: HarlanStenn,

Student: JohannesMaximilianKuehn

About the project

This project's goal is to write a reference implementation of the SNTP client using the latest NTPv4 document. As this shall become a reference implementation there's a focus on portability and light weight.

Project related questions

We thought not to implement a demon option but that might cause various problems. For example KoD packets might be an issue as SNTP runs and forgets after it's done. How could this be avoided?

Another tricky issue is DNS resolving. gethostbyname() for example poses a risk to get stuck. Asynchronous resolvers like from libisc or libdns are pretty heavy and therefor go against our goal to make it a lightweight client.

Links

http://www.mxiesoft.com My blog on which I'm writing about the project's progress

Related Topics:


 

Implementation Milestones

Description % Done Delivery Date
Biweekly Status Report 100 20080606
Biweekly Status Report   20080620
Biweekly Status Report   20080704
Begin Midterm Evaluation   20080707
Midterm Evaluation Due   20080714
Biweekly Status Report   20080718
Biweekly Status Report   20080801
Soft "Pencils Down"   20080811
Biweekly Status Report   20080815
Hard "Pencils Down"   20080818
Final Evaluation   20080901

 

Biweekly Status Reports

Biweekly status report, 6th June 2008

Two weeks have passed now since the official coding time began. During the first week I searched for good starting points for coding. Even though (or because?) the gross structure was more or less fix before coding started, I sat there trying to come up with pro and contra arguments which approach might be the best. Nevertheless finding no answer I decided to start with the asynchronous DNS resolver until I found a good starting point for SNTP coding (asynchronous DNS resolving was never meant to be a part in line with the other SNTP relevant parts in my milestones/schedule so I'll work on it parallel to SNTP once the SNTP client code has progressed far enough).

I started with searching and examining the relevant RFCs what appeared more difficult than assumed. Still the right docs were soon found and with the specification of the communication between DNS server and client I began to code. It was really nice to implement parts of this protocol but I should have taken more care of my bad habit of "reinventing the wheel" or doing everything myself. Thanks to a little Email exchange with a former Bind developer I became aware of that soon enough to not waste too much time on that and also to understand many things about DNS resolving better. Yet I think it wasn't very much wasted time as I understand the spec very well thanks to that so it'll make my work on it later easier. Even though I knew that we want to use as much as possible existing code it was also a good lesson to see better when and how I should do that.

So after that I began coding on the main program. I figured it might be the best to start here and to code the other parts as they are needed with the knowledge exactly how and when they're needed. Implemented command-line options parsing with ntp_getopts and everything that follows up to DNS resolving (not async resolving yet) and testing the addresses returned by the resolver whether they're reachable or not. Currently I'm working on the functions to receive and send data through the network.

For DNS resolving functions I decided to use the following interface (I'm currently using getaddrinfo, I'll implement libdns for that probably later today, too but since we planned to write an asynchronous resolver we'll have at least 2 different functions for DNS resolving so a common interface will give greater flexibility):

int resolver_function (char *host[], int hostc, struct addrinfo **res);

resolver_function consumes a list of hostnames, the number of hostnames and a pointer of a array of addrinfo structures. addrinfo structures themselves are linked lists (structures with a next pointer to another addrinfo structure until this pointer is NULL) with information on every IP address returned by the resolver.

I used getaddrinfo in order to study the functionality and information we need about the hosts passed to the SNTP client. I knew of getaddrinfo but as gethostbyname always did the job for me I never digged deep enough to figure out getaddrinfo's benefits. There's no way around protocol independent programming for a modern networking application like SNTP today.

To sum the last two weeks up, I see now a clear path how to code this SNTP client. Even though I think I'm a bit slow I guess that's normal at the beginning as I already saw that things speed up a lot after I knew how to approach the coding for the SNTP client. Also time management is still a bit of an issue for me. I haven't figured out the best schedule for myself yet. Right now I'm working mostly from Thursday to Sunday on it while I usually spend the whole Friday and Saturday on this project. I'm currently trying to balance the workload a bit more on all days. But I think the major working time wont change as Monday to Wednesday is just way too busy at university.


Project progress

Reviewed existing SNTP and NTP code, decided on commandline options and most design choices and put all that into a concrete blueprint according to which I'll write this implementation. There are still quite a few questions that will have to be answered, right now I'm working on answers to them as they come as I'm currently writing mostly only the framework stuff.


Discussion

There is a decent chance we will not need to do async DNS resolution for SNTP (which means we would not need libdns/), and we may not need to use taskmgr() for the loop processing.

If SNTP can properly handle its logging, then the only thing we might need libisc/ for would be some network handling code.

Is this correct? If so, what are the costs/befits to using libisc/ v. doing it ourself?

-- HarlanStenn - 17 May 2008

libisc/ is a double edged sword. While in terms of portability it would be our first choice it goes against the lightweight policy I'd like to follow as far as reasonable. As for example DNS resolution there are three possibilities: gethostbyname() (which we surely want to avoid), async resolver with =libisc/='s taskmgr or writing one myself (which might be more time consuming than I can imagine at the moment, will check that).

As for logging I think we decided to use =libisc/='s logging facilities. If people want to use something different (for example when using it on an embedded device), no problem.

-- JohannesMaximilianKuehn - 28 May 2008

 
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r17 < r16 < r15 < r14 < r13 | More topic actions...
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback