Slashdot Mirror
Expert Network Time Protocol
Ben Rothke writes "If you review the thousands of Internet RFCs, you'd be hard pressed to find a protocol that lends itself to philosophical overtones, save for one -- the Network Time Protocol (NTP). The nature of time is abstract, difficult to measure and highly subjective. Yet time is a critical element in everyone's life, and in the effective operations of corporate networks." Read on for the rest of Rothke's review.
Expert Network Time Protocol: An Experience in Time with NTP
author
Peter Rybaczyk
pages
176
publisher
Apress
rating
9
reviewer
Ben Rothke
ISBN
1590594843
summary
Expert Network Time Protocol is a fascinating look into NTP, and the stories behind the science
NTP is built on top of the TCP/IP protocol suite and is used to ensure accurate time-keeping with a trusted time reference. These references can be radio signals, GPS satellites, atomic clocks, Internet-based time servers and more. NTP is powerful enough to synchronize network clocks with millisecond accuracy.
In Expert Network Time Protocol: An Experience in Time with NTP, Peter Rybaczyk merges the philosophical aspects of time with the nuts of bolts of the NTP protocol. The book is composed of two parts, the first concerned with the meta-philosophy of time, and the second detailing the inner workings of NTP. The attempt in part one to merge technology and science with philosophy is a daunting task, and most often does not succeed. The notable exception to this is Douglas Hofstadter's Gödel, Escher, Bach: An Eternal Golden Braid.
Rybaczyk creates Sam, a fictional character who walks through the history of time. It is unclear who this Sam is -- whether he is supernatural being, or someone who got root on a time server. The author writes that the transcendental nature of time and the nuts and bolts of NTP are inseparable, but I personally found it difficult to determine what message part one was meant to convey. Fortunately, part one takes up but the first 34 pages.
Where the book shines, and where most readers will find value, is in part two, which details how to effectively design, configure, deploy and operate NTP. Where part one is conceptual, part two is extremely practical. Chapter 3 opens up with a comprehensive overview of the what, how and why effective time-keeping via NTP is needed.
The book details from a business perspective why synchronized and accurate time is a universal need. From transactional integrity, airline departures, sporting events, job shift changes, to FedEx pickups and more, nearly every activity requires time synchronization to work at peak levels. Effective network administration also requires time synchronization for network login procedures, directory synchronization, backups, and routing stability to work accurately.
From an information security perspective, password and digital ID synchronization, log file accuracy and auditing, and access control security are just a few of the areas where correct time can mean the difference between success and failure.
Where time synchronization is crucial, though, is in the realm of digital forensics. An otherwise painstaking digital forensic process might be worthless if time-related evidence from network devices is not correctly synchronized. If network devices are not correctly synchronized, you can basically forget about using them in any type of legal case.
Attorney Ronald Coleman, partner and computer law litigator at the New Jersey-based Coleman Law firm explains that in a computer law case involving serious discrepancies in network log times, the prosecution would conceivably drop the case. Similarly, a civil case to recover damages from an attacker is seriously undercut by these seemingly innocuous timing mistakes. "The network managers' lack of diligence at ensuring that the time was synchronized on their systems," explains Coleman, "opens them up to serious questions in front of a jury as to whether the logs and the system data are reliable at all -- especially with a gap of more than a couple of minutes, which might be explained away by which clocks were being relied on." In fact, an error of this magnitude would make the entire network administration suspect. That could be a disaster, Coleman says, where the network tracing record plus the human beings who sloppily set the automation in motion are going to be the chief sources of evidence against the alleged computer criminal. "A snafu such as seriously unsynchronized logs is just the sort of opening that could raise the level of doubt needed to undermine the other side's case."
Chapter 3 concludes with an interesting look at the cutting edge of time protocols, specifically the Interplanetary Internet. The Interplanetary Internet project is an attempt to synchronize computer time within the realm of deep space. NASA will in due time establish a deep space infrastructure whose purpose is to support the communication needs of multiple missions. Such an infrastructure would require time synchronization, but within a radically different framework from what exists today. The Interplanetary Internet and its underlying time synchronization are intended to solve that.
Chapter 4 brings the reader back to earth and provides vital information about how to design an effective NTP architecture. The key to designing the most appropriate NTP architecture for a given infrastructure is to first understand the different modes that NTP devices can operate in. The chapter details the five different NTP modes, the mode categories, and gives configuration information about each mode.
The chapter also provides information about NTP security. While NTP versions 3 and 4 provide added security (including symmetric private key cryptography and support of the Autokey protocol), it is ultimately up to the organization to determine what level of NTP security they need. Those organizations that don't require accurate time won't need much NTP security. But for those organizations who business requires synchronized and accurate time, such issues will drive the implementation of how they deploy NTP and its security functionality.
Chapter 5 details how organizational motivations (again, from a business perspective) will affect how you design your NTP architecture, and then describes several use scenarios. The book notes that designing an effective NTP deployment is a process that embodies four key steps: choosing a time source, deciding upon the NTP topology, determining the NTP features to configure, and then monitoring and managing the NTP operations. The chapter then goes on to describe various ways these steps can be carried out. The chapter provides a comprehensive overview on how to deploy NTP, be it on a dedicated time server, via already deployed products such as Cisco or Juniper routers, or on Unix/Linux/Windows file servers.
It is important to note that NTP is just the protocol. The actual implementation of NTP requires separate software client and server applications. The book focuses on the protocol and does not get into any specific vendors, other than a few screen shots from the configuration menu of a Symmetricom time server.
The author notes that on the surface, NTP is simple and almost inconspicuous, and overshadowed by better-known protocols such as HTTP, FTP and DNS. But once you start digging into NTP, you are dealing with one of the most pervasive elements of existence, namely time. Within NTP's scope, one could be dealing with atomic clocks, GPS satellites, clock selection, encryption algorithms and much more. So while at its heart, NTP may be a simple protocol, there is a complex infrastructure beneath it.
NTP is one of the most fundamental, yet overlooked services in the TCP/IP suite, and time synchronization is one of the most overlooked areas in networking. Hopefully, a book such as this can spark a renaissance. For far too long, time synchronization has not been afforded due diligence, and the effects have at times been disastrous. A view of the archives of the Risk Forum digest attests to this fact.
After a somewhat murky start in part one, Expert Network Time Protocol: An Experience in Time with NTP provides the reader with a superb synopsis of nearly everything he needs to know about NTP and effective time synchronization on his network, from an experienced implementer in the field. It is a fascinating look at one of the most humble, yet fundamental protocols on the Internet. For those who care about the correct time on their network, this book is required reading.
Ben Rothke, CISSP is a New-York based security consultant with ThruPoint, Inc. and the author of Computer Security: 20 Things Every Employee Should Know. He can be reached at ben@rothke.com You can purchase Expert Network Time Protocol: An Experience in Time with NTP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
NTP is built on top of the TCP/IP protocol suite and is used to ensure accurate time-keeping with a trusted time reference. These references can be radio signals, GPS satellites, atomic clocks, Internet-based time servers and more. NTP is powerful enough to synchronize network clocks with millisecond accuracy.
In Expert Network Time Protocol: An Experience in Time with NTP, Peter Rybaczyk merges the philosophical aspects of time with the nuts of bolts of the NTP protocol. The book is composed of two parts, the first concerned with the meta-philosophy of time, and the second detailing the inner workings of NTP. The attempt in part one to merge technology and science with philosophy is a daunting task, and most often does not succeed. The notable exception to this is Douglas Hofstadter's Gödel, Escher, Bach: An Eternal Golden Braid.
Rybaczyk creates Sam, a fictional character who walks through the history of time. It is unclear who this Sam is -- whether he is supernatural being, or someone who got root on a time server. The author writes that the transcendental nature of time and the nuts and bolts of NTP are inseparable, but I personally found it difficult to determine what message part one was meant to convey. Fortunately, part one takes up but the first 34 pages.
Where the book shines, and where most readers will find value, is in part two, which details how to effectively design, configure, deploy and operate NTP. Where part one is conceptual, part two is extremely practical. Chapter 3 opens up with a comprehensive overview of the what, how and why effective time-keeping via NTP is needed.
The book details from a business perspective why synchronized and accurate time is a universal need. From transactional integrity, airline departures, sporting events, job shift changes, to FedEx pickups and more, nearly every activity requires time synchronization to work at peak levels. Effective network administration also requires time synchronization for network login procedures, directory synchronization, backups, and routing stability to work accurately.
From an information security perspective, password and digital ID synchronization, log file accuracy and auditing, and access control security are just a few of the areas where correct time can mean the difference between success and failure.
Where time synchronization is crucial, though, is in the realm of digital forensics. An otherwise painstaking digital forensic process might be worthless if time-related evidence from network devices is not correctly synchronized. If network devices are not correctly synchronized, you can basically forget about using them in any type of legal case.
Attorney Ronald Coleman, partner and computer law litigator at the New Jersey-based Coleman Law firm explains that in a computer law case involving serious discrepancies in network log times, the prosecution would conceivably drop the case. Similarly, a civil case to recover damages from an attacker is seriously undercut by these seemingly innocuous timing mistakes. "The network managers' lack of diligence at ensuring that the time was synchronized on their systems," explains Coleman, "opens them up to serious questions in front of a jury as to whether the logs and the system data are reliable at all -- especially with a gap of more than a couple of minutes, which might be explained away by which clocks were being relied on." In fact, an error of this magnitude would make the entire network administration suspect. That could be a disaster, Coleman says, where the network tracing record plus the human beings who sloppily set the automation in motion are going to be the chief sources of evidence against the alleged computer criminal. "A snafu such as seriously unsynchronized logs is just the sort of opening that could raise the level of doubt needed to undermine the other side's case."
Chapter 3 concludes with an interesting look at the cutting edge of time protocols, specifically the Interplanetary Internet. The Interplanetary Internet project is an attempt to synchronize computer time within the realm of deep space. NASA will in due time establish a deep space infrastructure whose purpose is to support the communication needs of multiple missions. Such an infrastructure would require time synchronization, but within a radically different framework from what exists today. The Interplanetary Internet and its underlying time synchronization are intended to solve that.
Chapter 4 brings the reader back to earth and provides vital information about how to design an effective NTP architecture. The key to designing the most appropriate NTP architecture for a given infrastructure is to first understand the different modes that NTP devices can operate in. The chapter details the five different NTP modes, the mode categories, and gives configuration information about each mode.
The chapter also provides information about NTP security. While NTP versions 3 and 4 provide added security (including symmetric private key cryptography and support of the Autokey protocol), it is ultimately up to the organization to determine what level of NTP security they need. Those organizations that don't require accurate time won't need much NTP security. But for those organizations who business requires synchronized and accurate time, such issues will drive the implementation of how they deploy NTP and its security functionality.
Chapter 5 details how organizational motivations (again, from a business perspective) will affect how you design your NTP architecture, and then describes several use scenarios. The book notes that designing an effective NTP deployment is a process that embodies four key steps: choosing a time source, deciding upon the NTP topology, determining the NTP features to configure, and then monitoring and managing the NTP operations. The chapter then goes on to describe various ways these steps can be carried out. The chapter provides a comprehensive overview on how to deploy NTP, be it on a dedicated time server, via already deployed products such as Cisco or Juniper routers, or on Unix/Linux/Windows file servers.
It is important to note that NTP is just the protocol. The actual implementation of NTP requires separate software client and server applications. The book focuses on the protocol and does not get into any specific vendors, other than a few screen shots from the configuration menu of a Symmetricom time server.
The author notes that on the surface, NTP is simple and almost inconspicuous, and overshadowed by better-known protocols such as HTTP, FTP and DNS. But once you start digging into NTP, you are dealing with one of the most pervasive elements of existence, namely time. Within NTP's scope, one could be dealing with atomic clocks, GPS satellites, clock selection, encryption algorithms and much more. So while at its heart, NTP may be a simple protocol, there is a complex infrastructure beneath it.
NTP is one of the most fundamental, yet overlooked services in the TCP/IP suite, and time synchronization is one of the most overlooked areas in networking. Hopefully, a book such as this can spark a renaissance. For far too long, time synchronization has not been afforded due diligence, and the effects have at times been disastrous. A view of the archives of the Risk Forum digest attests to this fact.
After a somewhat murky start in part one, Expert Network Time Protocol: An Experience in Time with NTP provides the reader with a superb synopsis of nearly everything he needs to know about NTP and effective time synchronization on his network, from an experienced implementer in the field. It is a fascinating look at one of the most humble, yet fundamental protocols on the Internet. For those who care about the correct time on their network, this book is required reading.
Ben Rothke, CISSP is a New-York based security consultant with ThruPoint, Inc. and the author of Computer Security: 20 Things Every Employee Should Know. He can be reached at ben@rothke.com You can purchase Expert Network Time Protocol: An Experience in Time with NTP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
NTP is built on top of the TCP/IP protocol suite and is used to ensure accurate time-keeping with a trusted time reference.
Ummm, doesn't NTP run over UDP?
... without any of that mumbo-jumbo from RFCs can be found here [warning: PostScript file]. It's well written, and the safeguards and filtering techniques are very interesting.
- shadowmatter
Yes, if you're into the meta-philosophy of timekeeping. If not, then the first part of this book obviously isn't for you.
All I know is that I have the two Domain Controllers sync to 6 outside machines (reliable servers)
Do you know enough about NTP to be able to evaluate whether those are good sources? If not, then the second part of this book may be useful.
All the computers in the network are within a second of eachother - and thats good nuff for me.
...you hope. As the reviewer said, precise synchronization is absolutely critical for forensic purposes. Can you conclusively demonstrate that Event A on machine Foo occurred before Event B on machine Bar? Would you be willing to testify to that fact if a conviction or monetary judgment were on the line?
Even if you don't think you need it, it's so trivially easy to get millisecond accuracy on all but the most unstable tickers that I never have understood why people don't sync their computers. If nothing else, it's nice to be able to set your watch to a known-accurate time source, then use that to set the rest of the clocks in your house. Am I the only one that hates seeing different times on the combination oven and microwave that has two separate displays within two feet?
Dewey, what part of this looks like authorities should be involved?
That's when Great Britain switched from the Julian to the Gregorian calendar. See http://webexhibits.org/calendars/year-text-British .html
I pretend to know more than I really do by mooching off google and wikipedia.
I'd bet on the second explanation... see below excerpt:
In September 1752 the Julian calendar was replaced with the Gregorian calendar in Great Britain and its American colonies. The Julian calendar was 11 days behind the Gregorian calendar, so 14 September got to follow 2 September on the day of the change. The result was that between 3 and 13 September, absolutely nothing happened!
Of course, the interesting part is that packets don't travel instantaneously. It's not enough to ask what the time is - you also need to know how long it takes the responder to answer. Furthermore, travel times aren't symmetric and you have to estimate how much of the total elapsed time between sending the request and receiving the answer occurs during each leg of the trip. Remember, the other guy faces the same constraints that you do - you can't just ask him for the answer.
Time synchronization is a deceptively simple concept. I'm very grateful that some very smart people have thought this through to a level of detail that I probably never would.
Dewey, what part of this looks like authorities should be involved?
Duuuude. Longitude is a brief history of the development of navigation and an interesting read. Whoda thunk that determining your longitude would be such a problem. Besides, it's short. But what I have found is that many, many technical books are either way to general about things you need to know and way to specific about stuff you do.
Chapter 1: Meet Sam
Chapter 1: Sam sets up NTP on Linux
Section1: Sam meets the man in the Red Hat: In this chapter Sam types rpm -i ntp.rpm && ntpd
Section2: Sam meets Mandrake: In this chapter Sam types urpmi ntp && ntpd
Section3: Sam meets Gentoo: In this chapter Sam types emerge ntp && ntpd
Section 4: Sam meets Debian and battles the GNU: In this chapter Sam types apt-get install ntp && ntpd
Chapter 2: Sam set up NTP on other Unixes
Section 1: In this chapter Sam meets puffy the blowfish and types pkg_add ntp.tgz && ntpd
Section 2: In this chaper Sam meets Beastie and types pkg_add ntp.tgz && ntpd
Section 3: In this chapter Sam battles his way to the Oracle at Solaris and types pkg_add ntp.tgz && ntpd
/* oops I accidentally made a comment, sorry */
"Status of this Memo...This RFC is a tutorial on the TCP/IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard."
Note the specific and correct first use of "TCP/IP protocol suite." No proper name has ever been given to the entire suite of Internet protocols, so the need has been filled through the use of terms such as "TCP/IP based" or "Internet Protocol suite." Such terms are often simplifed to "TCP/IP" or "IP" for sake of brevity, at the expense of correctness, as is the case in RFC1180. Subsequent usage there is of an abbreviated form, suitable for a tutorial, although technically incorrect.
You're obviously unaware of the nature of RFCs. Historically, anyone could write anything and submit it as an RFC, correctness be damned. As RFC30 states: "The content of a NWG note may be any thought, suggestion, etc. related to the HOST software or other aspect of the network. Notes are encouraged to be timely rather than polished...These standards (or lack of them) are stated explicitly for two reasons. First, there is a tendency to view a written statement as ipso facto authoritative, and we hope to promote the exchange and discussion of considerably less than authoritative ideas." For you to base an argument on RFC1180 being somehow authoritative in regard to terminology simply demonstrates your lack of understanding of both RFCs and the reason for RFC1180, which is not to define terminology, but to describe the IP forwarding process.
If you examine the actual standards (i.e. STD5/RFC791/IP and STD7/RFC793/TCP) you will not find the terms used with such imprecision. Since the trigger for this thread branch is UDP, it's helpful to examine STD6/RFC768. It is clear from a reading that UDP works with IP, but is separate and distinct from TCP. UDP is no more a part of TCP/IP than is 802.3 Ethernet, although they're commonly used together.
I won't even call you an idiot, because you're obviously thinking, just ignorant of the facts.
I'll also point out that Internet is capitalized when used to refer to the global internet based on the IP suite of protocols. When not capitalized, it can refer to any network, not limited to those based on IP. IPX, Decnet, Appletalk, OSI suites of protocols can all be used to form internets.
"National Security is the chief cause of national insecurity." - Celine's First Law