From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 75299200A76 for ; Mon, 20 Aug 2012 13:41:49 -0700 (PDT) Received: by vcdd16 with SMTP id d16so13515871vcd.16 for ; Mon, 20 Aug 2012 13:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oiSN0shcmsng9YVW1CxmpWGFqvSmcjZnw25yCaIKSV8=; b=u5lIOyLMkVNSqu8MsWhE5giwEzKi+VYgrB49gnDsDjwRY1TIX8PmfjZLtVfZd8F8wp ux6o+MJwTCYHv1afb/jPfL8khnLPfKkrBKE42F4ABrJZd3vimnPf4fJk4XNly8AzggsU LRWVtRYaHPLtRkZNNScoOGc5WKHVOuAgEjQwAKsAnnVWc6qS4H0lSZvFcDjrnyuyOugp RhKGjp9gvsCvH7W3SkvRW8gljdTJuLbjttYG71NM4+Z6STBK5Mwa2R1W0mJAC0w9yAo6 32xkQ2f2xG+rJIwFROoK3fNP0947rh58cdV5qPc9l6KCP47XMv05exuv/KSioqASoIAw Ibbw== MIME-Version: 1.0 Received: by 10.58.94.44 with SMTP id cz12mr12480105veb.34.1345495308377; Mon, 20 Aug 2012 13:41:48 -0700 (PDT) Received: by 10.58.231.234 with HTTP; Mon, 20 Aug 2012 13:41:48 -0700 (PDT) In-Reply-To: References: <502E064C.50305@etorok.net> <502E9609.5040800@etorok.net> <9246.1345321014@sandelman.ca> Date: Mon, 20 Aug 2012 16:41:48 -0400 Message-ID: From: George Lambert To: david@lang.hm Content-Type: multipart/alternative; boundary=047d7b6dcaf0e71ccc04c7b88921 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17: nice latency improvements, some issues with bind X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 20:41:49 -0000 --047d7b6dcaf0e71ccc04c7b88921 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Check and set the time by syncing to NTP Servers - not user supplied times if the network is available. to see if they have set times > those set by NTP Server http://tf.nist.gov/tf-cgi/servers.cgi The global address *time.nist.gov* is resolved to all of the server addresses below in a round-robin sequence to equalize the load across all of the servers. Network Time Protocol (RFC-1305) The Network Time Protocol (NTP) is the most commonly used Internet time protocol, and the one that provides the best performance. Large computers and workstations often include NTP software with their operating systems. The client software runs continuously as a background task that periodically gets updates from one or more servers. The client software ignores responses from servers that appear to be sending the wrong time, and averages the results from those that appear to be correct. Many of the available NTP software clients for personal computers don=92t d= o any averaging at all. Instead, they make a single timing request to a signal server (just like a Daytime or Time client) and then use this information to set their computer=92s clock. The proper name for this type = of client is SNTP (Simple Network Time Protocol). The NIST servers listen for a NTP request on port 123, and respond by sending a udp/ip data packet in the NTP format. The data packet includes a 64-bit timestamp containing the time in UTC seconds since January 1, 1900 with a resolution of 200 ps. Most of the NIST time servers do not require any authentication when requesting the time in NTP format, and no keys or passwords are needed to use this service. In addition to this standard NTP service (which will not be modified), we have begun testing an authenticated version of NTP using a single time server that implements the symmetric key encryption method defined in the NTP documentation. In order to use this server, you must apply to NIST for an encryption key, which will be linked to the network address of your system. This service is being offered on an experimental basis only, and it may not be continued after the initial testing period. For more details, please see the authenticated ntp description . Daytime Protocol (RFC-867) This protocol is widely used by small computers running MS-DOS and similar operating systems. The server listens on port 13, and responds to requests in either tcp/ip or udp/ip formats. The standard does not specify an exact format for the Daytime Protocol, but requires that the time is sent using standard ASCII characters. NIST chose a time code format similar to the one used by its dial-up Automated Computer Time Service (ACTS), as shown below: *JJJJJ YR-MO-DA HH:MM:SS TT L H msADV UTC(NIST) OTM* where: - JJJJJ is the Modified Julian Date (MJD). The MJD has a starting point of midnight on November 17, 1858. You can obtain the MJD by subtracting exactly 2 400 000.5 days from the Julian Date, which is an integer day number obtained by counting days from the starting point of noon on 1 January 4713 B.C. (Julian Day zero). - YR-MO-DA is the date. It shows the last two digits of the year, the month, and the current day of month. - HH:MM:SS is the time in hours, minutes, and seconds. The time is always sent as Coordinated Universal Time (UTC). An offset needs to be applied to UTC to obtain local time. For example, Mountain Time in the U= . S. is 7 hours behind UTC during Standard Time, and 6 hours behind UTC during Daylight Saving Time. - TT is a two digit code (00 to 99) that indicates whether the United States is on Standard Time (ST) or Daylight Saving Time (DST). It also indicates when ST or DST is approaching. This code is set to 00 when ST = is in effect, or to 50 when DST is in effect. During the month in which the time change actually occurs, this number will decrement every day until = the change occurs. For example, during the month of November, the U.S. chang= es from DST to ST. On November 1, the number will change from 50 to the act= ual number of days until the time change. It will decrement by 1 every day until the change occurs at 2 a.m. local time when the value is 1. Likewi= se, the spring change is at 2 a.m. local time when the value reaches 51. - L is a one-digit code that indicates whether a leap second will be added or subtracted at midnight on the last day of the current month. If the code is 0, no leap second will occur this month. If the code is 1, a positive leap second will be added at the end of the month. This means t= hat the last minute of the month will contain 61 seconds instead of 60. If t= he code is 2, a second will be deleted on the last day of the month. Leap seconds occur at a rate of about one per year. They are used to correct = for irregularity in the earth's rotation. The correction is made just before midnight UTC (not local time). - H is a health digit that indicates the health of the server. If H =3D = 0, the server is healthy. If H =3D 1, then the server is operating properly= but its time may be in error by up to 5 seconds. This state should change to fully healthy within 10 minutes. If H =3D 2, then the server is operatin= g properly but its time is known to be wrong by more than 5 seconds. If H = =3D 3, then a hardware or software failure has occurred and the amount of th= e time error is unknown. If H =3D 4 the system is operating in a special maintenance mode and both its accuracy and its response time may be degraded. This value is not used for production servers except in specia= l circumstances. The transmitted time will still be correct to within =B11 second in this mode. - msADV displays the number of milliseconds that NIST advances the time code to partially compensate for network delays. The advance is currentl= y set to 50.0 milliseconds. - The label UTC(NIST) is contained in every time code. It indicates that you are receiving Coordinated Universal Time (UTC) from the National Institute of Standards and Technology (NIST). - OTM (on-time marker) is an asterisk (*). The time values sent by the time code refer to the arrival time of the OTM. In other words, if the t= ime code says it is 12:45:45, this means it is 12:45:45 when the OTM arrives= . On Mon, Aug 20, 2012 at 4:16 PM, wrote: > On Sat, 18 Aug 2012, Michael Richardson wrote: > > If we are writing the file system such that time can really never go >> backwards, then we are pretty much immune to most replay attacks >> > > If time cannot go backwards, what do you do if someone accidently sets th= e > time in the future? > > David Lang > > ______________________________**_________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.**bufferbloat.net > https://lists.bufferbloat.net/**listinfo/cerowrt-devel > --=20 P THINK BEFORE PRINTING: is it really necessary? This e-mail and its attachments are confidential and solely for the intended addressee(s). Do not share or use them without approval. If received in error, contact the sender and delete them. --047d7b6dcaf0e71ccc04c7b88921 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Check and set the time by syncing to NTP Servers - not user supplied times = if the network=A0
is available. to see if they have set times > thos= e set by NTP Server=A0


The = global address=A0time.nist.gov=A0is resolved to all of the server addresses be= low in a round-robin sequence to equalize the load across all of the server= s.


Network Time Protocol (RFC-1305)

The Network Time Protocol (NTP)= is the most commonly used Internet time protocol, and the one that provide= s the best performance. Large computers and workstations often include NTP = software with their operating systems. The client software runs continuousl= y as a background task that periodically gets updates from one or more serv= ers. The client software ignores responses from servers that appear to be s= ending the wrong time, and averages the results from those that appear to b= e correct.

Many of the available NTP software clients for personal computers do= n=92t do any averaging at all. Instead, they make a single timing request t= o a signal server (just like a Daytime or Time client) and then use this in= formation to set their computer=92s clock. The proper name for this type of= client is SNTP (Simple Network Time Protocol).

The NIST servers listen for a NTP request on port 123, and respond b= y sending a udp/ip data packet in the NTP format. The data packet includes = a 64-bit timestamp containing the time in UTC seconds since January 1, 1900= with a resolution of 200 ps.

Most of the NIST time servers do not require any authentication when= requesting the time in NTP format, and no keys or passwords are needed to = use this service. In addition to this standard NTP service (which will not = be modified), we have begun testing an authenticated version of NTP using a= single time server that implements the symmetric key encryption method def= ined in the NTP documentation. In order to use this server, you must apply = to NIST for an encryption key, which will be linked to the network address = of your system. This service is being offered on an experimental basis only= , and it may not be continued after the initial testing period. For more de= tails, please see the=A0authenticated ntp description.

Daytime Protocol (RFC-867)

This protocol is widely used by small computers running MS-DOS and similar = operating systems. The server listens on port 13, and responds to requests = in either tcp/ip or udp/ip formats. The standard does not specify an exact = format for the Daytime Protocol, but requires that the time is sent using s= tandard ASCII characters. NIST chose a time code format similar to the one = used by its dial-up=A0Automated Computer Time Service (ACTS), as sho= wn below:

JJJJJ YR-MO-DA HH:MM:SS TT L H msADV U= TC(NIST) OTM

where:

  • JJJJJ is the M= odified Julian Date (MJD). The MJD has a starting point of midnight on Nove= mber 17, 1858. You can obtain the MJD by subtracting exactly 2 400 000.5 da= ys from the Julian Date, which is an integer day number obtained by countin= g days from the starting point of noon on 1 January 4713 B.C. (Julian Day z= ero).

  • YR-MO= -DA is the date. It shows the last two digits of the year, the month, and t= he current day of month.

  • HH:MM:SS is the time in hours, minutes, and seconds. The time is always sen= t as Coordinated Universal Time (UTC). An offset needs to be applied to UTC= to obtain local time. For example, Mountain Time in the U. S. is 7 hours b= ehind UTC during Standard Time, and 6 hours behind UTC during Daylight Savi= ng Time.

  • TT is= a two digit code (00 to 99) that indicates whether the United States is on= Standard Time (ST) or Daylight Saving Time (DST). It also indicates when S= T or DST is approaching. This code is set to 00 when ST is in effect, or to= 50 when DST is in effect. During the month in which the time change actual= ly occurs, this number will decrement every day until the change occurs. Fo= r example, during the month of November, the U.S. changes from DST to ST. O= n November 1, the number will change from 50 to the actual number of days u= ntil the time change. It will decrement by 1 every day until the change occ= urs at 2 a.m. local time when the value is 1. Likewise, the spring change i= s at 2 a.m. local time when the value reaches 51.

  • L is = a one-digit code that indicates whether a leap second will be added or subt= racted at midnight on the last day of the current month. If the code is 0, = no leap second will occur this month. If the code is 1, a positive leap sec= ond will be added at the end of the month. This means that the last minute = of the month will contain 61 seconds instead of 60. If the code is 2, a sec= ond will be deleted on the last day of the month. Leap seconds occur at a r= ate of about one per year. They are used to correct for irregularity in the= earth's rotation. The correction is made just before midnight UTC (not= local time).

  • H is = a health digit that indicates the health of the server. If H =3D 0, the ser= ver is healthy. If H =3D 1, then the server is operating properly but its t= ime may be in error by up to 5 seconds. This state should change to fully h= ealthy within 10 minutes. If H =3D 2, then the server is operating properly= but its time is known to be wrong by more than 5 seconds. If H =3D 3, then= a hardware or software failure has occurred and the amount of the time err= or is unknown. If H =3D 4 the system is operating in a special maintenance = mode and both its accuracy and its response time may be degraded. This valu= e is not used for production servers except in special circumstances. The t= ransmitted time will still be correct to within =B11 second in this mode.
  • msADV= displays the number of milliseconds that NIST advances the time code to pa= rtially compensate for network delays. The advance is currently set to 50.0= milliseconds.

  • The l= abel UTC(NIST) is contained in every time code. It indicates that you are r= eceiving Coordinated Universal Time (UTC) from the National Institute of St= andards and Technology (NIST).

  • OTM (= on-time marker) is an asterisk (*). The time values sent by the time code r= efer to the arrival time of the OTM. In other words, if the time code says = it is 12:45:45, this means it is 12:45:45 when the OTM arrives.



On Mon, Aug 20, 2012 at 4:= 16 PM, <david@lang.hm> wrote:
On Sat, 18 Aug 2012, Micha= el Richardson wrote:

If we are writing the file system such that time can really never go
backwards, then we are pretty much immune to most replay attacks

If time cannot go backwards, what do you do if someone accidently sets the = time in the future?

David Lang

_______________________________________________
Cerowrt-devel mailing list
Ce= rowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel



--
= P THINK BEFORE PRINTING: is it really necessary?

This e-mail and its= attachments are confidential and solely for the
intended addressee(s). = Do not share or use them without approval. If received in error, contact th= e sender
and delete them.
--047d7b6dcaf0e71ccc04c7b88921--