Subject: Re: [ntpwg] What's the current thinking on rate limiting?

From: Sharon Goldberg <[email-masked]>
Date: Thu, 31 Mar 2016 16:59:00 -0400

Thanks. For the record see the "priming the pump" attack in our paper:

https://eprint.iacr.org/2015/1020.pdf

On Thursday, March 31, 2016, Harlan Stenn <[email-masked]> wrote:

> Miroslav Lichvar writes:
> > Yes, that is a security issue in the implementation of rate limiting
> > in ntpd, which was published last year. You may have seen posts from
> > authors of the paper on this list :). The fix is to respond randomly
> > when the clients appear to be sending too many requests, so they can't
> > be starved from responses completely. At least one NTP implementation
> > already does that.
>
> We're now doing a number of different things along those lines.  There
> are probably more things we could do, too.
>
> H
> _______________________________________________
> ntpwg mailing list
> [email-masked] <javascript:;>
> http://lists.ntp.org/listinfo/ntpwg
>
>

-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Sharon Goldberg <[email-masked]>
Date: Tue, 5 Apr 2016 14:28:07 -0400

Dear WG,

To follow up on my comments on draft-stenn-ntp-suggest-refid-00 at the
IETF'95 WG meeting just now. The current draft requires the use of an
extension field.  I believe the goals of the draft can be accomplished
without using an extension field, in a backwards compatible fashion.

The goal of the draft is to limit the information exposed by the REFID
while still preserving robustness to "length-1" timing loops where system A
takes time from system B, but system B takes time from system A.
This proposal allow system A to limit the info it leaks in its refID,
without harming any of its legacy clients.

Suppose system A is taking time from system B. Then there are two cases:
1) If A gets a time query from system B, A puts the IP of B in the refID of
its response. This way, even a legacy B can tell it cannot take time from A
because this would cause a timing loop.

2) If A gets a time query from system C, A puts a "nonsense" value in its
refID.  Even a legacy C can see that its IP is not in the refID, and so it
is allowed to take time from A.

One question is what this "nonsense" value should be.  I think it should be
a fixed value. For example 0.0.0.0.  We would not want a randomly-chosen
value since this might collide with actual IP addresses on the network.

Thanks,
Sharon

---

From: Sharon Goldberg <[email-masked]>
Date: Tue, 5 Apr 2016 14:42:27 -0400

All, just to summarize the conversation on meetcho just now. I think  that
this proposal would also solve the problem hashed IPv6 addresses colliding
with IPv4 addresses on the same network, which is addressed
in draft-stenn-ntp-ipv6-refid-hash-00.

Why? Because the only time a server will put an IP address in the refID
field is when it is responding to a query from *that specific IP*.  (Else,
it puts the "nonsense" value in the refID.)  So even if a collision
happens, it should not matter, since the only party to see the collision is
the IP that sent the query.

Sharon

On Tue, Apr 5, 2016 at 2:28 PM, Sharon Goldberg <[email-masked]> wrote:

> 1) If A gets a time query from system B, A puts the IP of B in the refID
> of its response. This way, even a legacy B can tell it cannot take time
> from A because this would cause a timing loop.
>
> One question is what this "nonsense" value should be.  I think it should
> be a fixed value. For example 0.0.0.0.  We would not want a randomly-chosen

---

From: Danny Mayer <[email-masked]>
Date: Tue, 5 Apr 2016 15:00:26 -0400

On 4/5/2016 2:28 PM, Sharon Goldberg wrote:
> extension field.Â  I believe the goals of the draft can be accomplished
> while still preserving robustness to "length-1" timing loops where
> system A takes time from system B, but system B takes time from system A. Â 
> without harming any of its legacy clients.Â 
> 
> 2) If A gets a time query from system C, A puts a "nonsense" value in
> its refID.Â  Even a legacy C can see that its IP is not in the refID,
> and so it is allowed to take time from A.Â 
> 
> One question is what this "nonsense" value should be.Â  I think it
> should be a fixed value. For example 0.0.0.0.Â  We would not want a
> randomly-chosen value since this might collide with actual IP addresses
> on the network.
> 
> Thanks,
> Sharon

The problem that I was alluding to in the jabber room is this. I'll keep
the problem simple and to one example.

A takes its time from B over an IPv4 address. A then gets a time query
from C over IPv6. How does it know if B and C are the same system or
different system? A has no information about that.

Is this clearer?

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 5 Apr 2016 15:01:02 -0400

Is this clearer?

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 05 Apr 2016 19:12:16 +0000

> value since this might collide with actual IP addresses on the network.

I think your proposal will usually work.

There is a potential problem in that A does not have complete
information about what B and C are doing.  It may be that B and C are
effectively the same machine/source of time, and that B and C would look
at the REFID returned by A and decide that there is a timing loop if A
is getting its time from B and C (which is also effectively B) is
considering using A for time.

If we're going for a strictly clean paradigm here we need to note this.

H

---

From: Sharon Goldberg <[email-masked]>
Date: Tue, 5 Apr 2016 15:21:16 -0400

On Tue, Apr 5, 2016 at 3:00 PM, Danny Mayer <[email-masked]> wrote:

> Yes, it's clear. How does the current ntpd implementation deal with this
problem?

Sharon

---

From: Danny Mayer <[email-masked]>
Date: Tue, 5 Apr 2016 15:28:00 -0400

On 4/5/2016 3:21 PM, Sharon Goldberg wrote:
> On Tue, Apr 5, 2016 at 3:00 PM, Danny Mayer <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > extension field.Ã‚Â  I believe the goals of the draft can be
>     accomplished
>     > system A takes time from system B, but system B takes time from
>     system A. Ã‚
>     > without harming any of its legacy clients.Ã‚
>     >
>     > its refID.Ã‚Â  Even a legacy C can see that its IP is not in the
>     refID,
>     > and so it is allowed to take time from A.Ã‚
>     >
>     > One question is what this "nonsense" value should be.Ã‚Â  I think it
>     > should be a fixed value. For example 0.0.0.0.Ã‚Â  We would not want a
> problem? Â 

Currently it doesn't. One of my proposals is for each system to generate
a RefID and use that for all interfaces. I'm not sure if that works for
all cases or causes other issues.

Danny

---

From: Sharon Goldberg <[email-masked]>
Date: Tue, 5 Apr 2016 16:54:17 -0400

> all cases or causes other issues.

OK. To clarify: you are proposing an extension to NTP where a server that
has multiple IP addresses can choose a special value as its refID, and
communicate that to its clients.  Then, if the clients choose to take time
from that server, they put that special value in as their refID, instead of
an IP address.

AFAIK this functionality is not part of NTP today, right? It would probably
require an extension field? Also its not backwards compatible, since a
server that chooses to do this would need to make sure that its clients
understand what it is doing. And currently clients don't know how to do
this, right?

Please clarify if I have misunderstood.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 05 Apr 2016 21:14:20 +0000

Danny Mayer writes:
> > =
> >     > To follow up on my comments on draft-stenn-ntp-suggest-refid-00 at =
> the
> >     > IETF'95 WG meeting just now. The current draft requires the use of =
> an
> >     > extension field.=C3=82=C2  I believe the goals of the draft can be
> >     accomplished
> >     > The goal of the draft is to limit the information exposed by the RE=
> FID
> >     system A. =C3=82
> >     > This proposal allow system A to limit the info it leaks in its refI=
> D,
> >     > without harming any of its legacy clients.=C3=82
> >     >
> >     > Suppose system A is taking time from system B. Then there are two c=
> ases:
> >     > 1) If A gets a time query from system B, A puts the IP of B in the =
> refID
> >     > of its response. This way, even a legacy B can tell it cannot take =
> time
> >     > 2) If A gets a time query from system C, A puts a "nonsense" value =
> in
> >     > its refID.=C3=82=C2  Even a legacy C can see that its IP is not in =
> the
> >     refID,
> >     > and so it is allowed to take time from A.=C3=82
> >     >
> >     > One question is what this "nonsense" value should be.=C3=82=C2  I t=
> hink it
> >     > should be a fixed value. For example 0.0.0.0.=C3=82=C2  We would no=
> t want a
> >     > randomly-chosen value since this might collide with actual IP addre=
> sses
> >     > on the network.
> >     >
> >     > Thanks,
> >     > Sharon
> > =
> 
> >     The problem that I was alluding to in the jabber room is this. I'll k=
> eep
> > =
> > =
> > =
> > problem? =C2 =
> > =

It *hasn't* been an issue.  It would be easy enough to address it if
somebody felt there was a need to, however.

The point is that with your proposal, Sharon, I'm not seeing that it is
possible to address this case.  That is separate from whether or not
it's a problem that needs to be addressed, now or in the "near" future.

It's clear that if A has multiple IPs on it (very common now, not common
20 years' ago) that A could check all of its IPs when it saw B's refid
and decide if any of them meant B was sync'd to A.

In reality, we have only seen that if A sends a packet to B, B responds
to that same address on that same IP.  We have had cases where that
response has come over a different interface.

There are other possiblities, though.

Here are more scenarios.

A VM host maintains the primary clock, and "guests" use that clock.  In
this case, if A and B are on the same VM host, their underlying system
clock is actually the same one.

And that assumes one (common) scenario - the VMs are likely set up so
that all the VMs have tightly-synchronized time.

There's another use case I've been looking for - a VM setup where I
can configure each VM to have a clock that behaves independently, so I
can test wider behaviors more easily.

Is it sufficient to check for loops of degree 1?  Exactly what problems
are we solving here?

What about the situation where a single refclock is directly feeding
multiple servers?  If A and B are getting their time from the same
refclock, should that mean A and B should not fall back on each other if
one of them loses signal to their shared refclock?

If A and B are talking to the same type of refclock is that something
that should be addressed?  There have been cases where broken firmware
has caused a family of refclocks to all take simultaneous leaps to the
same spot in the weeds.

If A and B are both using GPS (for example) and there is a system glitch
where GPS time is affected, is that also a timing loop that we'd want to
avoid?  This happened in Jan 2016.

What about a group of systems that share a PPS signal?  The PPS signal
might become untrustworthy, or the "source of numbered seconds" might
break.

Many of these issues are currently(!) insignificant in a LAN setting
where we're looking at timing/frequency sync to around the millisecond
level (roughly).  I don't *know*, but I'd bet they are significant when
trying to get to the microsecond level, let alone the nanosecond level.
Hello PTP.  Hello RADclock and the work PHK is doing with the algorithms
he's using on Ntimed.  Once we learn more about these, we need to make
sure these different choices will "play nice" with each other.

Similarly, chrony uses algorithms that are slightly different from the
ones NTP uses.  We haven't seen studies of any potential loop
instabilities between these two approaches, either.

I mention this because 20 years' ago we thought we were doing well
getting clocks to sync to within a tenth of a second.  Now, getting
sub-millisecond sync on a LAN is common.  I've spoken with folks who
told me that with some care and support, they are getting sync levels
with NTP that are very close to what they get with PTP - down to the
range of nanoseconds.  Where will we be 10 years' time from now?

I recall PHK saying that with PTP (or PTP-like stuff), he was able to
get offset and frequency sync on cold start in less than a second.  He
was doing this with a poll interval of about -9, or about 500
polls/second.

I know DLM was solving a real and evidenced problem with the refid and
loop detection.

It's looking like we need to take a stronger look at this to decide if
those problems are still significant, and if different problems are
becoming significant.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 05 Apr 2016 21:33:56 +0000

Sharon Goldberg writes:
>>>     The problem that I was alluding to in the jabber room is >>>
>>>     this. I'll keep the problem simple and to one example.
>>>
>>>     A takes its time from B over an IPv4 address. A then gets a time
>>>     query from C over IPv6. How does it know if B and C are the same
>>>     system or different system? A has no information about that.
>>>
>>>     Is this clearer?
>>>
>> Currently it doesn't. One of my proposals is for each system to
>> generate a RefID and use that for all interfaces. I'm not sure if
>> that works for all cases or causes other issues.
> 
> OK. To clarify: you are proposing an extension to NTP where a server
> that has multiple IP addresses can choose a special value as its
> refID, and communicate that to its clients.  Then, if the clients
> choose to take time from that server, they put that special value in
> as their refID, instead of an IP address.

My proposal for SUGGEST-REFID is simply a mechanism for an NTP instance
to tell others "If you use me as your system peer, please use <FOO> as
your refid."

If a server chooses to suggest a single nonce for all of its interfaces
as its suggested refid, great.  If it chooses to use that same nonce for
all of its associations, that's great too.

For me, we're now in the realm of "policy", and there are tradeoffs
there.

My goal was to provide a robust mechanism to allow for these policy
choices.

> AFAIK this functionality is not part of NTP today, right? It would
> probably require an extension field? Also its not backwards
> compatible, since a server that chooses to do this would need to make
> sure that its clients understand what it is doing. And currently
> clients don't know how to do this, right?

Danny's (policy) proposal would most likely be implemented using the
suggest-refid EF proposal I made, so:

Yes, an EF

Nobody is doing this yet, unless somebody has implemented my proposal
and not told me.

As for backward compatibility, that's not really an issue.  An old
server will not understand the EF so it will use the current rules for
choosing its refid when selecting its system peer.

This is what I talked about in my first "set", covering the I-Do and
Last-EF proposals.  If I send you packets with I-Do and get back a plain
response, I know you can't or aren't willing to do these newer choices.
Either way, I need to be prepared to check the legacy and suggested
refid choices in responses I get from you.

If I send you an I-Do and get *no* response, then I don't know if you
never got my packet or you got it and dropped it because it had an
unrecognized EF in it.  Eventually I would just send plain packets.

H

---

From: Danny Mayer <[email-masked]>
Date: Tue, 5 Apr 2016 22:02:14 -0400

On 4/5/2016 4:54 PM, Sharon Goldberg wrote:
>     >Â  Â  Â The problem that I was alluding to in the jabber room is this. I'll keep
>     >Â  Â  Â the problem simple and to one example.
>     >
>     >Â  Â  Â A takes its time from B over an IPv4 address. A then gets a time query
>     >Â  Â  Â from C over IPv6. How does it know if B and C are the same system or
>     >Â  Â  Â different system? A has no information about that.
>     >
>     >Â  Â  Â Is this clearer?
>     >
>     > problem? Ã‚
> that has multiple IP addresses can choose a special value as its refID,
> and communicate that to its clients.Â  Then, if the clients choose to
> take time from that server, they put that special value in as their
> refID, instead of an IP address.
> 
> probably require an extension field? Also its not backwards compatible,
> since a server that chooses to do this would need to make sure that its
> clients understand what it is doing. And currently clients don't know
> how to do this, right?
> 

You did misunderstand. I said the Refid itself and not an extension
field so it would be interoperable. I'm of the opinion that a server
should only have one refid for all interfaces no matter which one is
being used to send the packet. I recall that there is an issue that
Harlan had to explain to me in excruciating detail as to why the
existing refid is the way it is today but I don't recall now the
details. We already have a problem where the hash of the IPv6 address
can conflict with a real IPv4 address.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 06 Apr 2016 03:56:24 +0000

> can conflict with a real IPv4 address.

If that would be your policy then the way to implement it is with the
suggest-refid EF proposal I submitted.

The legacy behavior is that "For S2+, I use the IPv4 (or partial hash of
the IPv6) address of my system peer as the refid."

If this situation is not clearly described in my proposal please show
where that information could be improved.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 6 Apr 2016 10:40:46 +0200

> to tell others "If you use me as your system peer, please use <FOO> as

I think an extension field that would allow servers to announce their
own refids to clients is an excellent idea and I'm glad someone is
working on it.

However, I'm not sure about the intended security use case of the
proposal. I'm still not convinced that hiding refid would be a major
problem for an attacker. I think the number of servers that most
clients use on the Internet is fairly small, it probably consist of
pool.ntp.org and the list of public servers maintained on the ntp.org
wiki. The attacker can probably restrict the list by geo location of
the client to a country zone with few hundred of servers at most. I
suspect in most cases the attacker would be able to succeed by sending
spoofed packets from all these servers.

If there is a security issue with clients accepting spoofed packets, I
think it should be fixed directly instead of adding some security
through obscurity.

I'd rather see this extension field used as a way to improve the
robustness of the protocol. As Danny pointed out, if servers announced
the same refid to all clients, they could reliably detect multihomed
hosts.

My suggestion is to modify the field so it includes also refids of all
upstream servers. The clients could then prevent synchronisation loops
longer than 2. Loops between 3 peers polling one another can happen
easily and currently the best recommendation to prevent them is to
use a "line" configuration for the peers instead of a fully connected
mesh. Also, if the clients knew all upstream refids, they could detect
duplicate servers in the paths to the stratum 1 servers and ignore
them or decrease their weight.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 06 Apr 2016 09:11:19 +0000

> spoofed packets from all these servers.

How do you define "the attacker would be able to succeed" in this case?

Refclocks are increasingly easy to use, too, and this sort of
knowledge/attack is not useful if somebody has a local refclock.

I don't know how valid it is to assume your geo location claim.

Finally, if an attacker is going after somebody's servers that means
the "victim" will be getting unsolicited responses, and we now alert on
that case.

There are other protections against these attacks in the current
codebase, too.

> think it should be fixed directly instead of adding some security

What do you suggest?  How does the current proposal make things worse in
any way?

> robustness of the protocol.

Huh?  I think you are conflating things here.  The proposal is a
*mechanism* and the value it contains is *policy*.

> As Danny pointed out, if servers announced

Then all a bad guy has to do is to send a time request to a target, see
what refid it gets, and then use that knowledge as an attack vector.

Also, there has been no demonstrated benefit that this "wider scope"
loop detection will be of any useful value.

> them or decrease their weight.

Can you demonstrate tangible problems with the current scheme and
tangible benefit with your solution?  Please also consider the security
ramifications.

I've seen lots of mesh setups - they have all worked fine.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 6 Apr 2016 12:39:12 +0200

> How do you define "the attacker would be able to succeed" in this case?

Sending a packet that will be accepted by the client and disrupting
the synchronisation.

> knowledge/attack is not useful if somebody has a local refclock.

Well, if everyone had a reliable refclock, we wouldn't need NTP. :)

> What do you suggest?  How does the current proposal make things worse in

If the implementation follows the recommendation to change the refid
randomly, a client can't detect if it's talking to the same server as
its server for instance.

>From how I read the draft, it seems to suggest it's a security
mechanism. The word "attacker" is used quite a few times. I'd rather
see the proposal going in the other direction, giving clients a better
view of the NTP network instead of hiding information.

If you don't see the benefits, that's ok. I just thought I should
write my suggestions and see if anyone agrees with that.

> what refid it gets, and then use that knowledge as an attack vector.

If the client is fixed to not accept spoofed packets, what exactly the
attacker can do with that information?

> tangible benefit with your solution?  Please also consider the security

For instance, if the client knew the same stratum 1 server is used by
multiple stratum 3 servers and they didn't agree with other sources,
they could be rejected as one assuming the stratum 1 server is bad.

> I've seen lots of mesh setups - they have all worked fine.

I've received reports on loops forming between three peers that
were polling one another when they stopped receiving time from their
upstream sources. I was able to reproduce that. It's not a critical
issue, but I think it would be nice if NTP could prevent that.

---

From: Hal Murray <[email-masked]>
Date: Wed, 06 Apr 2016 13:20:48 -0700

[refid discussion]

[email-masked] said:
> If you don't see the benefits, that's ok. I just thought I should write my
> suggestions and see if anyone agrees with that. 

I think that's an important idea.  We need to consider the trade-offs between 
security from hiding the real refid compared to the forensic value of being 
able to figure out what is or was going on.

On the other hand, I don't have a handful of stories where it has been 
helpful so maybe it isn't really important.  Is a warm-fuzzy feeling worth 
anything?

> attacker can do with that information? 

It tells the bad guys one of the servers a system is using.  That is probably 
useful targeting information, either for DoS or for infiltration via phishing 
or exploit.

[email-masked] said:
> I've received reports on loops forming between three peers that were polling
> one another when they stopped receiving time from their upstream sources. I
> was able to reproduce that. It's not a critical issue, but I think it would
> be nice if NTP could prevent that. 

Doesn't that case bump the stratum level each time around the loop until is 
falls off the end?

-- 
These are my opinions.  I hate spam.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 06 Apr 2016 21:52:29 +0000

> Sending a packet that will be accepted by the client and disrupting

I think we're approaching a workable definition there.  It depends on
"accepted by the client" and "disrupting".

To me, the goal of the protocol includes (and this needs more tweaking,
too):

- weed out flagrantly bad packets
- update some core peer state data
- perform  thorough packet checks
- if these checks pass, send the packet to the filters

Even then, bogus or otherwise bad packets will get thru.  The algorithms
are designed to deal with these problems.

> Well, if everyone had a reliable refclock, we wouldn't need NTP. :)

I notice the smiley.  Even so, that's an incomplete, myopic, and
insufficient oversimplication.

> randomly, a client can't detect if it's talking to the same server as

I'm not seeing where you think the current proposal is worse in any way.

As for your response/suggestion, where is this recommendation to change
the refid randomly?

In the case where I suggest a refid and you choose me as your server and
use my suggested refid as your system peer, even if I change this on
every poll interval it will be pretty easy for me to track these random
refids and still detect a loop.  Yes, it means saving some state.  The
server suggesting the refid has control over if it uses the same refid
for everybody or not, and also for how often it chooses to change its
suggested refid.  This is a local policy choice.

Even if the client is broken and uses us as their server giving us a
refid we do not understand, in that case there will be a timing loop and
each poll interval the stratum on each side will increase.  Eventually,
these systems will either find another peer to get time from or they'll
both become unsync'd (because there is no other source of time).  This
is no different from A noticing that B is getting its time from A,
refusing to take time from B, and either getting time from somewhere
else or just changing its state to unsynch'd (S16).

> view of the NTP network instead of hiding information.

Yes, it's a security mechanism.  And please remember that we're trying
to get away from the expectation that an S2+ refid is an IPv4 address,
because that is increasingly incorrect.  Also note we're about to make
it easy to control "who can see what", so if you want to know who my
upstream server really is and you have the authorization to get that
information, that would be made available thru a mode 6 query.

> write my suggestions and see if anyone agrees with that.

I wouldn't do what you and Danny are suggesting, but if you want to do
things that way it's your choice - that's why I'm saying my proposal
offers a mechanism, and while we'll provide a default policy choice on
what that suggested refid will be, there will also be mechanism in the
config file to allow you to specify your local policy on what that
suggested refid will be and the circumstances under which that
suggesteed refid will change.

> attacker can do with that information?

How can anybody detect that an incoming packet has a forged source
address?

> they could be rejected as one assuming the stratum 1 server is bad.

How would you propose this work in practice?

This seems to be a special case of a Sybil attack.  I think the overhead
this would introduce would be huge and is better addressed elsewhere, by
proper monitoring and having enough upstream servers.

> issue, but I think it would be nice if NTP could prevent that.

Were these 3 machines the only source of time?  Are they set up in
orphan mode?

What would have happened if this loop had been prevented?

H

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 07 Apr 2016 05:48:36 +0000

Hal Murray writes:
> I think that's an important idea.  We need to consider the trade-offs
> between security from hiding the real refid compared to the forensic
> value of being able to figure out what is or was going on.

As I said before, the real source of time is available from a mode 6
query.

How can y'all not know this, even without my pointing it out?

H

---

From: Hal Murray <[email-masked]>
Date: Wed, 06 Apr 2016 23:21:37 -0700

[email-masked] said:
> As I said before, the real source of time is available from a mode 6 query. 

My system doesn't automatically log that.  The remove system probably does 
log it, but I probably don't have convenient access to those log files.

If the reason the remove server is hiding the real refid is to prevent the 
bad guys from figuring out which servers it is using, then mode 6 access is 
probably blocked.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 07 Apr 2016 06:35:30 +0000

Hal Murray writes:
> My system doesn't automatically log that.  The remove system probably
> does log it, but I probably don't have convenient access to those log
> files.

How did you get from a mode 6 query to a log file?

> If the reason the remove server is hiding the real refid is to prevent
> the bad guys from figuring out which servers it is using, then mode 6
> access is probably blocked.

a) the "real refid" is not being hidden.  The express purpose of the
refid is maintained.

b) if you have a valid reason for issuing mode 6 queries and the "other
side" doesn't choose to allow this, that's their policy choice.  In that
case you can continue to use them for time, or not.  Your policy choice.

H

---

From: Hal Murray <[email-masked]>
Date: Thu, 07 Apr 2016 01:32:21 -0700

> How did you get from a mode 6 query to a log file?

You said I could get the real refid via mode 6,
  
The context I was thinking about was forensics.  I'm often interested in what 
has happened rather than what is happening.  In that case, all the evidence 
that is available is what's in the log files.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 07 Apr 2016 08:52:31 +0000

> You said I could get the real refid via mode 6,

No, I said you could get the address of the upstream peer with mode 6.

> The context I was thinking about was forensics.  I'm often interested
> in what has happened rather than what is happening.  In that case, all
> the evidence that is available is what's in the log files.

That may be OK with IPv4 refids, but how do the current logfiles help
you with IPv6-based refids?

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 7 Apr 2016 10:57:06 +0200

> able to figure out what is or was going on.

I agree.

> helpful so maybe it isn't really important.  Is a warm-fuzzy feeling worth 

I think it could be more than just a warm-fuzzy feeling. I think
knowing refids up to stratum 1 could be useful for NTP clients to make
better decision in the source selection and also for administrators
when debugging problems.

Harlan referred to mode 6. That's not always available. It's not a
part of the current NTPv4 spec (it was optional in the NTPv3 spec) and
AFAIK only ntpd implements it. Also, on servers accessible from
Internet it's normally disabled as it allows amplification.

> Doesn't that case bump the stratum level each time around the loop until is 

It does. The trouble is that unless the servers have a local reference
enabled (e.g. orphan mode), they will stuck to stratum 16, 15, ... and
will be unusable for clients one, two, ... layers below.

As I said, I don't think it's a huge deal, but it would be nice if NTP
could prevent that.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 7 Apr 2016 11:32:25 +0200

> As for your response/suggestion, where is this recommendation to change

Your draft says:
  A system that decides to send a Suggested REFID extension field
  SHOULD generate a new Suggested REFID for each new association.

I'm assuming this is about client associations distinguished by IP
address (ignoring the fact the multiple clients may be behind one
address). If the server sends different refids to different clients,
the clients won't be able to detect that they are a client of another
client of the same server.

Older ntpd versions had a check for that. While we may argue about how
useful it really is, it will no longer be possible if the suggestion
is implemented.

> How can anybody detect that an incoming packet has a forged source

The cookie (aka origin timestamp) in the reply doesn't match the request.

> proper monitoring and having enough upstream servers.

It would complicate the selection algorithm, no doubt about that,
but that's the choice of the implementation.

> Were these 3 machines the only source of time?

Yes.

> Are they set up in orphan mode?

No.

> What would have happened if this loop had been prevented?

Alarms monitoring the synchronisation would not be triggered. The
servers would stay in a synchronised state with a real reference and
could be used by their clients and clients of their clients for few
hours until the upstream servers were reachable again.

---

From: Sharon Goldberg <[email-masked]>
Date: Thu, 7 Apr 2016 06:28:27 -0400

My proposal is orthogonal to what is being discussed here.   I believe it
can be implemented alongside Harlan's proposal in suggest-refid.

I want to emphasize that my proposal is backwards compatible and can be
implemented today without an extension field.  Whereas Harlan's idea is
super clever but it requires both the client and the server to understand
an extension field.

First off, to reiterate why I care about this, pretty much all the off-path
attacks that we and Cisco have done have the following first step:

Query the target client. Get the response. Learn its refID. Now you know
the client's server. $Attack the server. (Potentially rinse and repeat if
the client moves to another server.)

Sure, mode 6 reveals this information but modern NTP configurations should
prevent remote IPs from launching mode 6 queries, as it is not only an
amplification vector and also leaks state making it easier to attack the
system.  (See also Cisco's "origin leak" bug [1].)  So I do not have a
"warm fuzzy" feeling when I see NTP leaking information. Especially since
most NTP traffic is not usually cryptographically protected.  I think NTP
should leak less information, not more.

My proposal offers a backwards compatible way for a system to limit the
information leaked in its reference ID. It solves the IPv6 refID collision
problem.  And it seems to be compatible with what NTP is doing today.

Some exceptions could be made for stratum 1 servers to broadcast to all
clients that your refID is GPS or some other external source, if this
really a problem.  But we should be sure its really a problem, because
information leakage always makes it easier to launch attacks.

Much of this discussion has been regarding a future use case in which a
client had two IP addresses B and C.   This client sends a query from
interface B and wants to make sure it is not in a timing loop with another
system A who is taking time from interface B.

One could deal with this usecase using Harlan's proposal, but this does not
preclude my proposal running in parallel.  To deal with this, the client "B
and C"  uses Harlan's extension field to signal "if you take time from me,
put this nonce as your refID."   If it decided to signal the *same* nonce
to all clients, it has explicitly taken on the risk than an attacker can
use this information as a first step in an attack, as I have described
above.  If it signals a different nonce to all clients, then it is
protected from this.

This non-backwards compatible feature would therefore only be used by
systems that need it, eg those that have two IP addresses. All other
systems could limit the amount of information being leaked in their refID
by using my proposal.

Sharon

[1] http://www.talosintel.com/reports/TALOS-2016-0078/
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Thu, 7 Apr 2016 13:48:26 -0400

On 4/7/2016 6:28 AM, Sharon Goldberg wrote:
> systems could limit the amount of information being leaked in their
> refID by using my proposal.
> 

The number of systems that don't have multiple addresses these days can
probably be counted on one hand. All newer O/S's support both IPv4 and
IPv6 addresses. Furthermore NTP has broadcast and multicast modes so
packets can also arrive over those addresses as well.

Harlan and I had a discussion on this yesterday and now I remember why
the current preferred server's address is being used in the refID. At
the time it was implemented it was meant to prevent timing loops and
security was not a worry. In today's world that's the primary worry.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 7 Apr 2016 14:31:21 -0400

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 07 Apr 2016 18:53:02 +0000

> can be implemented alongside Harlan's proposal in suggest-refid.

Agreed.

> the client moves to another server.)

The bad guy can impersonate the client and "vex" the server, and the bad
guy can also impersonate the server and "vex" the client.

> information leakage always makes it easier to launch attacks.

The refid changes affect S2+ only, we'd leave S1 refids alone.

> system A who is taking time from interface B.

The timing loop issue has 2 aspects (at least).  I'll talk about one of
them now.

One reason to avoid a timing loop has to do with sailing off into the
weeds.  I'm not sure how significant this case is anymore.  If I only
have 1 source of time, well, we know what that means.  If that source of
time only has me as their source of time then the timing loop stuff
means we'll detect this immedately and we'll both go out-of-sync.  But
if we do not detect this loop, if A is at S2 then B is at S3.  When
we're down to no additional sources of time, at that point A will become
S4 and B will be come S5, then it goes to S6/S7, ... until the machines
go out of sync.  In this case that will happen in 6 poll intervals.

If there are no other sources of time available, then is it significant
that the machines go out of sync after 1 or 2 poll intervals instead of
6?

I'm using round numbers here.

A semblance of order would be in place if the boxes were configured
using orphan mode, or even local refclocks.

So I'd really like to know exactly what the concerns are about this
particular "failure mode".

H
--
> --001a1142b68e529239052fe28ce7
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><div><div><div><div>My proposal is orthogonal to what is b=
> eing discussed here.=C2=A0=C2=A0 I believe it can be implemented alongside =
> Harlan&#39;s proposal in suggest-refid.<br><br>I want to emphasize that my =
> proposal is backwards compatible and can be implemented today without an ex=
> tension field.=C2=A0 Whereas Harlan&#39;s idea is super clever but it requi=
> res both the client and the server to understand an extension field.<br></d=
> iv><br>First off, to reiterate why I care about this, pretty much all the o=
> ff-path attacks that we and Cisco have done have the following first step:<=
> br><br></div>Query the target client. Get the response. Learn its refID. No=
> w you know the client&#39;s server. $Attack the server. (Potentially rinse =
> and repeat if the client moves to another server.)<br><br></div><div>Sure, =
> mode 6 reveals this information but modern NTP configurations should preven=
> t remote IPs from launching mode 6 queries, as it is not only an amplificat=
> ion vector and also leaks state making it easier to attack the system.=C2=
> =A0 (See also Cisco&#39;s &quot;origin leak&quot; bug [1].)=C2=A0 So I do n=
> ot have a &quot;warm fuzzy&quot; feeling when I see NTP leaking information=
> . Especially since most NTP traffic is not usually cryptographically protec=
> ted.=C2=A0 I think NTP should leak less information, not more.<br><br></div=
> ><div>My proposal offers a backwards compatible way for a system to limit t=
> he information leaked in its reference ID. It solves the IPv6 refID collisi=
> on problem.=C2=A0 And it seems to be compatible with what NTP is doing toda=
> y.<br></div><div><div><br></div>Some exceptions could be made for stratum 1=
>  servers=20
> to broadcast to all clients that your refID is GPS or some other=20
> external source, if this really a problem.=C2=A0 But we should be sure its=
> =20
> really a problem, because information leakage always makes it easier to=20
> launch attacks. <br><br></div><div>Much of this discussion has been regardi=
> ng a future use case in which a client had two IP addresses B and C.=C2=A0=
> =C2=A0 This client sends a query from interface B and wants to make sure it
>  is not in a timing loop with another system A who is taking time from=20
> interface B.=C2=A0 <br><br>One could deal with this usecase using Harlan&#3=
> 9;s proposal, but this does not preclude my proposal running in parallel.=
> =C2=A0 To deal with this, the client &quot;B and C&quot;=C2=A0 uses Harlan&=
> #39;s extension field to signal &quot;if you take time from me, put this no=
> nce as your refID.&quot;=C2=A0=C2=A0 If it decided to signal the *same* non=
> ce to all clients, it has explicitly taken on the risk than an attacker can=
>  use this information as a first step in an attack, as I have described abo=
> ve.=C2=A0 If it signals a different nonce to all clients, then it is protec=
> ted from this.</div><br></div>This non-backwards compatible feature would t=
> herefore only be used by systems that need it, eg those that have two IP ad=
> dresses. All other systems could limit the amount of information being leak=
> ed in their refID by using my proposal.<br><div><br><div>Sharon<br><br>[1] =
> <a href=3D"http://www.talosintel.com/reports/TALOS-2016-0078/">http://www.t=
> alosintel.com/reports/TALOS-2016-0078/</a><br></div><br><div><br></div></di=
> v></div>
> 
> --001a1142b68e529239052fe28ce7--
> 
> --===============5243542199967168099==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============5243542199967168099==--
>

---

From: brian utterback <[email-masked]>
Date: Sat, 9 Apr 2016 11:52:46 -0400

Miroslav's erratum (id 4504) is still listed as "reported" for RFC 5905.
I think the consensus from this discussion was that the LI can be set
for more than a day so the erratum is incorrect and the current wording
is correct. What is the process for getting the erratum marked as
"denied" in some way?

On 6/16/2015 5:47 AM, David Malone wrote:
> On Tue, Jun 16, 2015 at 08:41:45AM +0000, Harlan Stenn wrote:
>> I will say we're well in to June and there are plenty of v4 servers out
>> there and we haven're received a bug report.
> Based on my data:
>
> 	http://www.maths.tcd.ie/~dwmalone/time/leaps/
>
> It looks like they've been advertised for more than a day for a
> long time. I could try and extract a bigger window, if that was
> useful.
>
> 	Daviid.

-- 
Oracle <http://www.oracle.com>
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049 <tel:+1%206038973049>
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
------------------------------------------------------------------------
All working systems eventually start to exhibit their own agenda
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 11 Apr 2016 09:27:51 +0200

> is correct. What is the process for getting the erratum marked as

Getting consensus on that first?

The current wording in RFC 5905 is conflicting. Once it says it's day
and once it says it's month. The RFC indicates several times the field
is meant to be compatible with NTPv3, where it was just day
(unambigiously).

The page referred below shows a vast majority of the servers started
announcing the last leap (June 2015) one day before, following the
NTPv3 definition. It seems it's only very old ntpd versions (pre RFC
5905) that announced it for month. Brian, I assume you are still
maintaining some old versions that do that and the "day" definition
would meant they have to be fixed?

If the intended interval for the leap bits in NTPv4 was really month,
the draft needs to be updated to not say the field is compatible with
NTPv3, like it does with the refid field. Clients that don't check
what day it is would need to be fixed. The old ntpd versions that
announce the leap for more than day would still be incompatible with
NTPv3.

Both choices have some drawbacks, there is no clear winner, but I
think the "day" definition is a better choice, at least for NTPv4.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 11 Apr 2016 08:39:11 +0000

> is meant to be compatible with NTPv3, where it was just day

Offhand, I don't recall the details of this well enough.  My belief is
that we've been doing the announcement a month in advance, but it will
be easy enough to check.

I do know that we've known for years that one problem is that it is the
poll interval can be 17, which is more than a day, so in that case it's
not enough to rely on the leap bits for this notification.

I think it needs to be allowed any time during the month where it can
happen.

Also note that for a while, *any* server that announced a leap second
was enough to trigger this condition.  This was a feature when the
majority of systems out there did not handle this well.  Now I think we
might have switched to a "majority vote" in the case where the local
system doesn't have a leapsecond file.  Or something like that.

H

---

From: Hal Murray <[email-masked]>
Date: Mon, 11 Apr 2016 03:20:18 -0700

GPS sends out the warning close to 6 months early.  The HP driver has a 
hack/patch to only pass that on in June and December.  (I added similar code 
to the Palisade driver for the recent leap.)

I looked in log files from last June.  It was only sent out one day in 
advance.

I looked around a bit, but didn't find the filtering in the main code.  I 
think it may be tangled up with the leap file code.

---

From: Greg Dowd <[email-masked]>
Date: Mon, 11 Apr 2016 15:42:09 +0000

I think GPS just has to be in the right 127 week window so it definitely can propagate quite early, that knocked a few receivers out a couple leap seconds ago.  As I've mentioned in the past, I've debated the properties of the leap second and it's propagation with Mills in the past without complete satisfaction, at least on my part :-)  As Harlan mentioned, the poll interval can exceed one day although that is really targeted at dialup which, other than NIST lockclock servers, is becoming obsolete.  Mills mentioned deep space probes as well but that is tucked pretty far into the corner case.

The goal, explicitly reviewed many times in the NTPv4 meetings at ietf and on the mailing list, was to allow advance notice of the impending leap.  The rationale was that ntp was not responsible for implementing the leap but merely for providing notice that the event was going to occur to the operating system.  As operating systems evolve, this model will continue to improve.  If we agree that the os needs to handle the event, then presumably the requirement to gate the event to a particular leap event window (primary June/Dec, optional Mar/Sept) seems reasonable.  

The current logic, as I understand it, is that a local reference clock, if it survives the clustering algo, is allowed to set the leap event independently.  If the source of the leap data is upstream via ntp, then a majority of the cluster has to agree to generate an event.  Actually, the one I have not experimented with is that autokey passes the leap file, if present, at the server end of the association.  At least it used to.  How that is processed I do not know.  

At the risk of boring the audience, I am yet again going to point out that the clearing of the event can also be an important piece of state information.  I  suppose since ntp is implemented as a user space, asynchronous application, any quasi real-time requirements are hard to mandate.  I have always believed that the leap indicator needed to be cleared immediately after the insertion/deletion.  The issue is that most implementations repeat the second on insertion.  When that occurs, there is an easy way to to distinguish the repeated time (which does violate the monotonic timescale concept) by using the leap bit set/clear as the unique element.  However, this can be tough to implement reliably in software so Mills was against it.  Even though he was against the concept, his earlier web documentation clearly showed the leap bits operating in the manner I described, at least from a computer science point of view.

So, currently the clear logic is simply the above logic so the bits are cleared on the next round through the peer select crunching.

Regardless of the choice, the input source (NIST ACTS, IRIG B-1344, PTP, NTP, GPS, Glonass) all use different time gates to provide warning so nothing is guaranteed.  I am always a proponent of the KISS principle so I think the current month logic in 5905 works.  

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+greg.dowd=[email-masked]] On Behalf Of Hal Murray
Sent: Monday, April 11, 2016 3:20 AM
To: Miroslav Lichvar
Cc: [email-masked]; [email-masked]
Subject: Re: [ntpwg] leap second: definitions and DCF-77

EXTERNAL EMAIL

GPS sends out the warning close to 6 months early.  The HP driver has a hack/patch to only pass that on in June and December.  (I added similar code to the Palisade driver for the recent leap.)

I looked in log files from last June.  It was only sent out one day in advance.

I looked around a bit, but didn't find the filtering in the main code.  I think it may be tangled up with the leap file code.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 12 Apr 2016 01:53:28 +0000

Greg Dowd writes:
> I think GPS just has to be in the right 127 week window so it
> definitely can propagate quite early, that knocked a few receivers out
> a couple leap seconds ago.  As I've mentioned in the past, I've
> debated the properties of the leap second and it's propagation with
> Mills in the past without complete satisfaction, at least on my part
> :-) As Harlan mentioned, the poll interval can exceed one day although
> that is really targeted at dialup which, other than NIST lockclock
> servers, is becoming obsolete.  Mills mentioned deep space probes as
> well but that is tucked pretty far into the corner case.

Yes, and as Ulrich mentioned, another problem is that clients may be
several layers deeper, so several poll intervals will be needed.
Multiples, if there is "consensus voting" going on.

> The goal, explicitly reviewed many times in the NTPv4 meetings at ietf
> and on the mailing list, was to allow advance notice of the impending
> leap.  The rationale was that ntp was not responsible for implementing
> the leap but merely for providing notice that the event was going to
> occur to the operating system.  As operating systems evolve, this
> model will continue to improve.  If we agree that the os needs to
> handle the event, then presumably the requirement to gate the event to
> a particular leap event window (primary June/Dec, optional Mar/Sept)
> seems reasonable.
> 
> The current logic, as I understand it, is that a local reference
> clock, if it survives the clustering algo, is allowed to set the leap
> event independently.  If the source of the leap data is upstream via
> ntp, then a majority of the cluster has to agree to generate an event.
> Actually, the one I have not experimented with is that autokey passes
> the leap file, if present, at the server end of the association.  At
> least it used to.  How that is processed I do not know.

I'd have to look, and I don't have time for that now.

Autokey is not recommended/deprecated.

Moving the leapseconds file around with NTS has not been proposed, and I
don't see the value in a means to do that, either via NTS or a new
extension field.

The update-leap script should be fine for that, and there are other,
similar ways otherwise dumb clients can get the leapseconds file
(libcurl or libfetch, for example).

> At the risk of boring the audience, I am yet again going to point out
> that the clearing of the event can also be an important piece of state
> information.

I agree.

> I suppose since ntp is implemented as a user space,
> asynchronous application, any quasi real-time requirements are hard to
> mandate.  I have always believed that the leap indicator needed to be
> cleared immediately after the insertion/deletion.

I agree.

> The issue is that
> most implementations repeat the second on insertion.  When that
> occurs, there is an easy way to to distinguish the repeated time
> (which does violate the monotonic timescale concept) by using the leap
> bit set/clear as the unique element.  However, this can be tough to
> implement reliably in software so Mills was against it.  Even though
> he was against the concept, his earlier web documentation clearly
> showed the leap bits operating in the manner I described, at least
> from a computer science point of view.

The above is true for POSIX timescales. 

NTF's General Timestamp API handles this better.  And there is a lot of
work to do there still.

> So, currently the clear logic is simply the above logic so the bits
> are cleared on the next round through the peer select crunching.

It also goes to "what happens when ntpd is queried just before, during,
and after a leap second event?"

H

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 12 Apr 2016 08:16:57 +0200

>>> Greg Dowd <[email-masked]> schrieb am 11.04.2016 um 17:42 in Nachricht
<[email-masked]>:
> I think GPS just has to be in the right 127 week window so it definitely can 
> propagate quite early, that knocked a few receivers out a couple leap seconds 
> ago.  As I've mentioned in the past, I've debated the properties of the leap 
> second and it's propagation with Mills in the past without complete 
> satisfaction, at least on my part :-)  As Harlan mentioned, the poll interval 
> can exceed one day although that is really targeted at dialup which, other 
> than NIST lockclock servers, is becoming obsolete.  Mills mentioned deep 
> space probes as well but that is tucked pretty far into the corner case.

I'd say long polling intervals are not for dial-up sources; they are for clocks that are raher stable compared to the jitter of the source. So the long polling interval will make the clock more stable than a short polling interval would (assuming that the clocks internal error is less then the jitter over the long polling interval). AFAIR, in NTP before v4 some integers would overflow with a longer polling interval, so it was not allowed...

> 
> The goal, explicitly reviewed many times in the NTPv4 meetings at ietf and 
> on the mailing list, was to allow advance notice of the impending leap.  The 
> rationale was that ntp was not responsible for implementing the leap but 
> merely for providing notice that the event was going to occur to the 
> operating system.  As operating systems evolve, this model will continue to 

NTP is also not responsible for implementing time, but as a leap second introduced an "error" of 1 second, the same care as for propagating the correct time has to be taken to correctly proagate leap second information (not to talk about implementing the switch).

> improve.  If we agree that the os needs to handle the event, then presumably 
> the requirement to gate the event to a particular leap event window (primary 
> June/Dec, optional Mar/Sept) seems reasonable.  

NTP being portable across platforms cannot make such assumptions easily, I'm afraid.

> 
> The current logic, as I understand it, is that a local reference clock, if 
> it survives the clustering algo, is allowed to set the leap event 
> independently.  If the source of the leap data is upstream via ntp, then a 
> majority of the cluster has to agree to generate an event.  Actually, the one 
> I have not experimented with is that autokey passes the leap file, if 
> present, at the server end of the association.  At least it used to.  How 
> that is processed I do not know.  

Maybe the idea was that clients could do additional verification...

> 
> At the risk of boring the audience, I am yet again going to point out that 
> the clearing of the event can also be an important piece of state 
> information.  I  suppose since ntp is implemented as a user space, 

I had commented on a message of Harlan on that, but I'm afraid I just replied to him (until recently).

> mandate.  I have always believed that the leap indicator needed to be cleared 
> immediately after the insertion/deletion.  The issue is that most 
> implementations repeat the second on insertion.  When that occurs, there is 
> an easy way to to distinguish the repeated time (which does violate the 
> monotonic timescale concept) by using the leap bit set/clear as the unique 
> element.  However, this can be tough to implement reliably in software so 
> Mills was against it.  Even though he was against the concept, his earlier 
> web documentation clearly showed the leap bits operating in the manner I 
> described, at least from a computer science point of view.
> 
> So, currently the clear logic is simply the above logic so the bits are 
> cleared on the next round through the peer select crunching.
> 
> Regardless of the choice, the input source (NIST ACTS, IRIG B-1344, PTP, NTP, 
> GPS, Glonass) all use different time gates to provide warning so nothing is 
> guaranteed.  I am always a proponent of the KISS principle so I think the 
> current month logic in 5905 works.  
> 
> 
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 12 Apr 2016 09:11:07 +0200

> I'd have to look, and I don't have time for that now.

If I understand the current code correctly, there is a timer which is
set in the source selection when the survivors are announcing a leap
second. One refclock is enough for that, with NTP sources there has to
be a majority.

On the last day of the month the timer sets the system leap status.
That is what NTP clients get. It doesn't matter if the leap was from a
refclock, the clients always see the leap only on the last day of the
month.

I agree it would be better if servers were allowed to announce it
sooner. But at this point I think it's about compatibility. There are
very few NTP server implementations and all recent versions seem to
announce it on the last day of the month. The number of client
implementations is much larger and we don't know how applications are
interpreting the leap status. To me it seems safer to stick with one
day interval for the announcement. Of course, in NTPv5 or some NTPv4
extension field it could be different.

As for the errata I submitted for RFC 5905, it's supposed to fix a
typo. The word "month" should have been "day" and it will be
consistent with the two other occurences of "day" and the following
sentence:

  A list of the packet header variables is shown in Figure 7 and
  described in detail below.  Except for a minor variation when using
  the IPv6 address family, these fields are backwards compatible with
  NTPv3.

---

From: brian utterback <[email-masked]>
Date: Tue, 19 Apr 2016 21:48:34 -0400

I have been trying to figure out the procedure for figuring out if there
is an extension field and/or a legacy MAC and where they are. This seems
to be covered in section 7.5.1. I am looking at this in terms of an
implementer. I feel that there is some length restriction left out of
the document because there seems to be cases as is that are ambiguous.

If the packet is 12 words long, there is no extension fields and no
legacy mac. No problem.

If the data past the first 12 words is greater then 24 octets, then we
know there is is at least on extension field, so we can read the length
of the first extension and move past it. If the length got us to the end
of the packet, we are done, there was one extension and no legacy MAC.

We know from 7.5.1.4 that if there is no MAC then the last extension in
the packet must be 28 octets or greater but an extension might be that
long and not be the last one. Also, there is no limit on how small an
extension might be if it is not the last. And there is no maximum or
minimum size of the legacy MAC if it is with an extension field. So,
after getting past the first extension field, unless it's length got me
to the end of the packet I can't say if what I am pointing to is an
extension or a MAC and I don't see a way to determine it. The same thing
happens if the residual data after the regular NTP packet is less than
24 octets. It might be a MAC, or it might be a short extension field
followed by a short MAC.

On 2/9/2016 1:39 AM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Time Protocol of the IETF.
>
>         Title           : The Network Time Protocol Version 4 (NTPv4) Extension Fields
>         Authors         : Tal Mizrahi
>                           Danny Mayer
> 	Filename        : draft-ietf-ntp-extension-field-07.txt
> 	Pages           : 8
> 	Date            : 2016-02-08
>
> Abstract:
>    The Network Time Protocol Version 4 (NTPv4) defines the optional
>    usage of extension fields. An extension field, defined in RFC5905, is
>    an optional field that resides at the end of the NTP header, and can
>    be used to add optional capabilities or additional information that
>    is not conveyed in the standard NTP header. This document updates
>    RFC5905 by clarifying some points regarding NTP extension fields and
>    their usage with Message Authentication Codes (MAC).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ntp-extension-field/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ntp-extension-field-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-extension-field-07
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 20 Apr 2016 05:47:28 +0000

brian utterback writes:
> I have been trying to figure out the procedure for figuring out if
> there is an extension field and/or a legacy MAC and where they
> are. This seems to be covered in section 7.5.1. I am looking at this
> in terms of an implementer. I feel that there is some length
> restriction left out of the document because there seems to be cases
> as is that are ambiguous.

I really don't see this as a big deal, and I don't think we need special
considerations.  I think I described all of this before, but I'm not
finding those emails.

There are two situations, newer code and older code.

With newer code, we can expect people to be using various combinations
of:

- unknown-EF: this should be more rare if folks implement I-Do
- MAC-EF
- Last-EF
- legacy MAC

Older code will, at best support:

- autokey
- legacy MAC

To go a bit beyond this, old code will have either a legacy MAC, or a
single autokey packet and a legacy MAC.  Nothing else, unless there are
unknown implementation that chose to use unregistered EFs.

An EF consists of 2 bytes of field type and 2 bytes of field length.

A MAC consists of a 4-byte key ID follwed by the digest.

It's pretty easy to do a test for an EF.  You can look up the Field Type
and see if it's anything expected or normal.  For the legacy case,
that's going to be a limited number of first byte values and a 2nd byte
of '2'.  The next 2 bytes must either equal the remaining length of the
data, or be less than the remaining length of data.

It's pretty easy to test for a legacy MAC.

The first 4-bytes will be a key ID, and for all known existing cases,
the digest payload will be a 16 byte MD5 key (20 bytes total), which
should be, by far, the most prevalent case.  Other cases include:

 MD2
 MD4
 MDC2
 RIPEMD160
 SHA
 SHA1

or any other hash algoritm the OpenSSL library supports.  These can be
256 or even 512 bit hashes.  So other legacy MAC lengths can easily be
24, 36, or 68 bytes long.  There are more possibilities.

The interesting thing here is the key ID.  If the key ID is < 65535,
this will be a symmetric key.  If we have that keyid in our tables, we
can validate it.  If we do not have that keyid in our tables, if this is
a legacy MAC we *cannot* validate it.  If the key ID is > 65535, it must
be an autokey session key and we can validate it if we have a matching
key, and we *cannot* validate it if it's not in our key list.

So we have a variety of ways to handle packets that have extra data in
them, and this boils down to:

- length checks: if it's an EF and there is extra data, what comes after?
- key ID checks
- there should never be a packet from an old system with more than 1 EF,
  and if an old system has 1 EF what comes next must be a legacy MAC
- current proposals have ways to completely avoid these problems

Please check out the relevant bits of RFC5905 and RFC5906.

I'm sure we can better document these things, if that is really
necessary and useful.

Can people screw things up and make things difficult?  Yes.  And I'd
like to see valid use-cases for these situations.

Let's be aware of the difference between "being thorough" and
"overengineering" in this case.

H

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 20 Apr 2016 05:53:09 +0000

I'll also add that I have a number of suggestions for improvements to
this document.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 20 Apr 2016 08:35:29 +0200

> the document because there seems to be cases as is that are ambiguous.

I think the algorithm needed for parsing extension fields and MACs in
NTP packets is supposed to be simple after this RFC. If special MACs
are not negotiated as described in 7.5.1.3, the parsing should be:

1. parse header of NTP packet (48 octets)
2. if remaining length == 0:
     return success
   else if remaining length >= 28:
     parse an extension field, if not valid return error
     move pointer by the length of the extension field
   else if remaining length in (4, 20, 24):
     parse legacy MAC
     return success
   else:
     return error
3. go to 2

> extension might be if it is not the last.

7.5 mentions the minimum length is 16 octets, this didn't change with
the new RFC. Are you saying it should be specified with a MUST?

> And there is no maximum or
> minimum size of the legacy MAC if it is with an extension field.

As the second paragraph in 1. says, legacy MACs are 4, 20 or 24 octets
long. This corresponds to NAK, MD5 and SHA1 MACs and should apply to
packets with and without extension fields.

> So,
> extension or a MAC and I don't see a way to determine it.

If the remaining length is >= 28, it should be an extension field.

> The same thing

It's a MAC, because last extension field is required to be at least 28
octets.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 20 Apr 2016 09:56:50 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 20.04.2016 um 07:47 in Nachricht
<[email-masked]>:

[...]

> should be, by far, the most prevalent case.  Other cases include:

Somewhat stupid question: You talk as if those data have a unique signature to tell what it is, but don't the key ID and the MD5 key look very much like random data (with no destince pattern)?

I'n in support for Brian, and as soid before, I'd appreciate an exact algorithm over all that text. As the past indicated, nobody wants to give a precise algorithm, probably because of non-determinedness. It seems you'll have to make several assumptions that are outside of the data packet.

> key, and we *cannot* validate it if it's not in our key list.

Won't an autokey look very much like random data?

>   and if an old system has 1 EF what comes next must be a legacy MAC

How to detect an "old system"?

> "overengineering" in this case.

Well, you cannot change the past, but for the future is much more preferrable to have one precise specification rather tahn a specification with multiple addendums and clarifications, partially contradicting previous specifications.

Regards,
Ulrich

---

From: Hal Murray <[email-masked]>
Date: Wed, 20 Apr 2016 02:07:45 -0700

>    else if remaining length in (4, 20, 24):

What is a 4 byte MAC?

I'm missing a key idea.  Why are legacy MACs allowed after new extension 
fields?  I'd expect them to have their own extension type.  That would clean 
up the extension parsing.

Does moving the test for the length of legacy MACs inside the loop simplifiy 
something?  I think it makes it harder to ever un-grandfather legacy MACs.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 20 Apr 2016 11:26:00 +0200

> >    else if remaining length in (4, 20, 24):

It's a crypto-NAK, the key ID is zero and there is no digest. It's
used in server reply when the client's MAC is invalid to let it know
the authentication is bad.

> up the extension parsing.

There is a new extension field proposed for MACs. Should it be a
requirement for clients that support new extension fields? The server
will still need to be able to parse packets from old clients.

> something?  I think it makes it harder to ever un-grandfather legacy MACs.

Legacy MACs are allowed in packets with extension fields. Until all
extension fields are parsed, we don't know where the MAC starts, so
I'm not sure how would that work.

---

From: brian utterback <[email-masked]>
Date: Wed, 20 Apr 2016 08:01:32 -0400

>    else if remaining length in (4, 20, 24):

That is not consistent with what is in the extensions draft. It may be
consistent with what was intended but it isn't with what it currently
says. As it stands, the only requirement that the last extension field
be >= 28 octets is if there is no MAC and at the time we are looking at
the length to see if it is >- 28 octets we do not know that yet. This
means that if it is less than 28 octets it might be two small extension
fields and not a MAC.

I think that Harlan's "last" extension might fix the problem, but it
should not be a separate extension. It needs to be added to 7822 to
update 5905. That is, for it to be useful it must be mandatory.
-- 
Oracle <http://www.oracle.com>
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049 <tel:+1%206038973049>
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
------------------------------------------------------------------------
All working systems eventually start to exhibit their own agenda
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 20 Apr 2016 15:24:19 +0200

On Wed, Apr 20, 2016 at 08:01:32AM -0400, brian utterback wrote:
> the length to see if it is >- 28 octets we do not know that yet.

Hm, I see.

> This

If extension fields are required to be at least 16 octets, two
wouldn't fit in 28 octets. An extension field and crypto-NAK would fit
there, however. If crypto-NAK wasn't allowed in packets with extension
fields (is it?), this would still work, or not? 

4 octets is crypto-NAK
20 octets is MD5 MAC
24 octets is SHA1 MAC
28 octets is 1 EF
32 octets is 1 EF
36 octets is 1 EF or 1 EF + MD5 MAC
40 octets is 1 EF or 1 EF + MD5/SHA1 MAC
44 octets is 1 EF or 1 EF + MD5/SHA1 MAC or 2 EF (16 + 28 octets)
...

The only change in the algorithm above would be a special case for 4
remaining octets with crypto-NAK.

> update 5905. That is, for it to be useful it must be mandatory.

The problem with the "last" extension is that it will need to be at
least 16 octets if old implementations should be able to parse and
reply to packets that have it, which I think would be a waste of
bandwidth.

If we were considering breaking compatibility, I'd rather see a
cleaner approach. Maybe allow legacy MACs only in packets that don't
have any extension fields. If length < 28, it's a MAC, otherwise there
are only extension fields. Autokey could be enabled for old clients
with a special option if necessary.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 20 Apr 2016 12:20:53 -0400

Yes.

> requirement for clients that support new extension fields?

If a new extension field requires a MAC it needs to use the MAC
extension field rather than the legacy one.

 The server
> will still need to be able to parse packets from old clients.

Yes. The new extension field does not need to require a legacy MAC as
long as other requirements don't require it (symmetric key is a case
that requires a legacy MAC).

> I'm not sure how would that work.

I have some ideas about how to do this, but it cannot be guaranteed to
not get the wrong results.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 20 Apr 2016 21:27:21 +0000

Miroslav,

You have eloquently described the problems I have with this document.

It claims to decree that things that were not required before are now
required, these things are not sufficient to fully address the problem,
and we need to do better.

H

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 20 Apr 2016 22:01:12 +0000

"Ulrich Windl" writes:
> Somewhat stupid question: You talk as if those data have a unique signature t
> o tell what it is, but don't the key ID and the MD5 key look very much like r
> andom data (with no destince pattern)?

They do have a unique structure.

How did I not clearly describe this?

We can sanity check EFs based on Field Type and Field Length.

We can sanity check legacy MACs because the first 4 bytes are a key ID
and we have knowledge there.

We're not operating in a vacuum here.

> I'n in support for Brian, and as soid before, I'd appreciate an exact algorit
> hm over all that text. As the past indicated, nobody wants to give a precise 
> algorithm, probably because of non-determinedness. It seems you'll have to ma
> ke several assumptions that are outside of the data packet.

Absolutely, and this is to be expected.

Why do we need to describe this in detail?  We don't describe lots of
other things in that level of detail.

Also, with the proposed new EFs, all of this "goes away".  Why do we
want to make it easy for people to run deprecated and outdated stuff?

> Won't an autokey look very much like random data?

Autokey looks like an EF.  It has to be explicitly configured on each
side, so it's *expected*.

If you don't support autokey and somebody sends you an autokey packet,
it's just like getting any other EF you don't recognize, except for many
years the *only* EF we listed was an autokey EF.

I don't see what you're concerned about.

> How to detect an "old system"?

What do you mean by "detect"?  Please describe the exact situation, as
that's important in this case.

> Well, you cannot change the past, but for the future is much more preferrable
>  to have one precise specification rather tahn a specification with multiple 
> addendums and clarifications, partially contradicting previous specifications
> .

Yes, and the proposed new EF proposals handle this, especially after we
address the problems caused by the just-installed new EF proposal.

H

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 21 Apr 2016 03:07:26 +0000

Danny Mayer writes:
>>> I'm missing a key idea.  Why are legacy MACs allowed after new
>>> extension fields?  I'd expect them to have their own extension type.
>>> That would clean up the extension parsing.
>> 

No it doesn't.  The rules were very clear until this document was
accepted.

The MAC-EF is arguably a *better* solution, but it's really no big deal
either way.

>> The server will still need to be able to parse packets from old
>> clients.
> 

symmetric key should not require a legacy MAC.  It should require "a
MAC".

>>> Does moving the test for the length of legacy MACs inside the loop
>>> simplifiy something?  I think it makes it harder to ever
>>> un-grandfather legacy MACs.
>> 

This is an implementation issue, and from everything I have seen it's
easily solvable.

>From my POV, the Standard should talk about "mechanism", and the
implementation is "policy".  We should be VERY careful about where we
specify policy in the Standard.

H

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 21 Apr 2016 09:10:01 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 21.04.2016 um 00:01 in Nachricht
>> hm over all that text. As the past indicated, nobody wants to give a precise 

Harlan,

it seems your mailer wraps quotes lines not obeying word boundaries; that looks a bit strange.

> other things in that level of detail.

Well, why not have a se of sample packets (binary images) as well as a reference interpretation of those. That way automatic tests could be used for any algorithm that tries to interpret those packets.

> want to make it easy for people to run deprecated and outdated stuff?

Do we want people driving cars using fossile fuel? ;-)

> that's important in this case.

If you receive packet you want to process, everything you need to know should be in that packet. Specifically for a connectionless protocol like UDP or a stateless protocol like NTP (in most cases at least).

Regards,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 21 Apr 2016 08:30:00 +0000

"Ulrich Windl" writes:
>>>> Harlan Stenn <[email-masked]> schrieb
> Well, why not have a se of sample packets (binary images) as well as a
> reference interpretation of those. That way automatic tests could be
> used for any algorithm that tries to interpret those packets.

Sure.  Great idea.  But with this sort of data there are still places
where choices on what to do are "policy" choices, and tests like these
are "mechanism" choices.

> Do we want people driving cars using fossile fuel? ;-)

That's policy.  We're talking about mechanism.

>>>> So we have a variety of ways to handle packets that have extra data
>>>> in them, and this boils down to:
>>>>
>>>> - there should never be a packet from an old system with more than
>>>>   1 EF, and if an old system has 1 EF what comes next must be a
>>>>   legacy MAC
>>>
>> What do you mean by "detect"?  Please describe the exact situation,
>> as that's important in this case.
> 
> If you receive packet you want to process, everything you need to know
> should be in that packet.

I don't think so.  And we remember lots of other stuff too, like origin
timestamps and previous other things, and there is state information we
must maintain for autokey.  Also symmetric key information is maintained
outside of the packet.

You should know all of this.

> Specifically for a connectionless protocol like 
> UDP or a stateless protocol like NTP (in most cases at least).

See above.

We get into a lot of trouble if we do too much or too little, or do
things in the "wrong" places.

H