Re: [ntpwg] Comments on new drafts

[Harlan Stenn <[e-mail]>]

Miroslav Lichvar writes:
> On Thu, Apr 07, 2016 at 09:16:26PM +0000, Harlan Stenn wrote:
> > Miroslav Lichvar writes:
> > > draft-mayer-ntp-mac-extension-field-00
> > > - Instead of hiding the hash function, I think it might be more useful
> > >   to specify it directly in the field to allow easier debugging when
> > >   the authentication fails. The MAC length field could be shortened to
> > >   one octet and the other octet could specify the key type, allowing
> > >   256 different types.
> > 
> > I see the cost of advertising the hash function.  I don't see the
> > benefit to advertising the hash function.  If there's a failure, that
> > should be a very rare event and it should be obvious how to fix it.
> 
> Beside knowing which hash function was used in the MAC, the type field
> will allow other MACs in the field, not just those used by
> authentication with symmetric keys.

The security folks tell me that it's better to not advertise the
algorithm.  If you get adequate consensus from them that it's not an
issue to publish the hash function then OK.

Why do you think the described proposal only allows symmetric key
encryption?  It supports autokey as well, and the only other proposed EF
that includes a MAC is NTS, and that protocol embeds its MAC in the NTS
packet, and once the key exchange is completed NTS provides its own MAC.

I asked if the NTS MAC could/should be separated out into a separate MAC
field and was told "No, we want it in the NTS EF."

Oh, what's stopping people from publishing 1 algorithm but actually
using another, again for security purposes?

> > If the hash function is communicated, I think there are probably better
> > ways to convey that information besides trying to save 1 byte.
> 
> If you want to keep the data aligned to 4 octets and not waste too
> much space, what else do you propose?

I already proposed what I think we should do.  Not encode the algorithm
in the MAC.  We've never done it before and there seems to be no
compelling reason to do it now.  There are other ways to get this
information, and they don't seem to be difficult to use.

> > I have no opinion as to whether or not we should limit the size of the
> > hash to ~256 bytes (if I understood that part correctly).
> 
> The size could be specified in multiplies of 4, if you think 256 is
> not enough. I don't.

I don't have the cycles to explore this right now.  We don't need to
think about this if we don't encode the algorithm in the MAC.  And right
now we expressly do not encode the algorithm in the MAC.

> > > - MACs could be treated as opaque data, not requiring symmetric keys
> > >   with 32-bit key IDs. This would allow storing MACs from new
> > >   authentication schemes and they wouldn't need a new extension field,
> > >   just a new MAC type for this extension field.
> > 
> > I don't understand "... they wouldn't need a new extension field, just a
> > new MAC type for this extension field."
> 
> The NTS MAC could be stored in this field for instance, it doesn't
> have to be a new extension field. If you had multiple MACs in this
> field packet, they would be independent. Their order wouldn't change
> the result, the second MAC wouldn't have to include the first one, the
> third MAC wouldn't need to include the first and second one, and so on.

The NTS designers have told me they do not want to do this.  The NTS
stuff uses its packet for a bunch of different things.  So you're
suggesting we don't use a new EF for NTS?

> > > draft-stenn-ntp-i-do-00
> > > - It's not clear to me why there needs to be a "MAC required" bit and
> > >   why it should be specified in this draft. This was discussed before,
> > >   but I've not seen any conclusion.
> > 
> > We've had MACs from before we had the first EF.  When autokey arrived,
> > it *required* a MAC.  Many years' later, we have now just added an
> > experimental EF that says "there MUST NOT be a MAC."
> 
> That information is included in the specification of the field. How
> will that bit change behaviour of an implementation that doesn't
> understand the field? It would be great if you could give an example
> of a difference in the processing of the packet when this bit is set
> and not set.

If I understand you, your first sentence means that the knowledge of
whether or not an EF expects a MAC is known because that knowledge is
embedded in the specification of that EF type.

That fails if the current NTP instance does not know how to process this
"new" EF.

As for examples of how the bits for MAC-OPTIONAL and MAC-INCLUDED, in
what way have I provided incomplete examples or supporting explanation
before?

> > > draft-stenn-ntp-ipv6-refid-hash-00
> > > - The idea was discussed several times before. It doesn't make much
> > >   sense to me. 
> > 
> > Then don't implement it, and don't announce that you support it in I-Do
> > exchanges.
> 
> If I don't implement it, I won't be able to detect loops with servers
> that do implement it. This is not an optional feature as I understand
> it. It changes the definition of the refid field in the NTPv4 packets
> and everyone has to deal with it.

It's one thing to use what is described for detection.  It's another
thing to decide to send them yourself.

1) if you implement I-Do then you will be able to say "I don't send this
style of IPv6 refid hash and I don't want you sent it to me, either."
It's up to the "other side" to decide if they're going to honor your
request.

2) You can implement as much or as little of this mechanism to detect
IPv6-based refid hashes as you wish, and decide how many of these
mechanisms to test for along the way.  As I said, this is pretty easy
and lightweight to do.

3) if the Suggest-REFID proposal is implemented, this is a non-issue.

4) if Sharon's idea for "Not-You REFID" is used, this is a non-issue.

5) There are a number of different mechisms proposed around REFIDs.
They are not mutually exclusive.  You should have the flexibility here
to implement a local policy you are comfortable with.

6) if somebody doesn't implement this and they do not detect a loop when
it exists, the stratum of each side will degrade every poll.  And if
they don't have enough other sources of time or they have misconfigured
their systems, and they're not properly monitoring their systems, that's
their problem.

> > > - In order to avoid conflicts with refids based on IPv4 addresses it
> > >   makes conflicts between refids based on IPv6 more likely. Why should
> > >   be IPv4 special? The world is quickly moving to IPv6.
> > 
> > It uses an initial octet that CANNOT appear as a source address, so
> > your argument that it "makes conflicts between refids based on IPv6 more
> > likely" seems ... wrong to me, at least for IPv4-based refids.
> 
> I mean conflict between two refids generated from two different IPv6
> addresses. Your proposal prevents a conflict between IPv6 refids and
> IPv4 refids, but at a cost that there will be more conflicts between
> IPv6 refids. The 32-bit IPv4 space would be mapped to 32 bits in
> refid, but the 128-bit IPv6 space only to 24 bits. Don't you see the
> problem?

Yes. There is a 1 in 16.7M chance of a collision in this case.

The decision to use this mechanism is a local policy choice.

There are collision risks with the original mechanism.

One can use REFID-SUGGEST to avoid this problem, potentially creating a
1 in 16.7M chance of collision with the original IPv6 hash mechanism.

One can use the Not-You refid proposal, which has a 1 in 4B chance of a
collision.

The cost of any of these collisions is that the other side will be
identified as a false-positive timing loop.

That should not be a real problem for anybody.

For REFID-SUGGEST it's possible to periodically change the nonce, which
would limit the period of time when this false-positive condition
exists.

Regardless, if you are a client, you're not serving time so you have no
timing loop issue to worry about.  If you only have 1 source of time,
you have different problems.  If there is benefit to combining the refid
loop detection code with a stratum check that may also be useful.

We have known, active problems with the current refid implementation.

Choose your poison.

> > > draft-stenn-ntp-leap-smear-refid-00
> > > - I don't think the refid field in NTP packet is a good place to store
> > >   an offset.
> > 
> > Where else can it go that it's obvious, visible, and almost totally
> > backward-compatible?
> 
> I think the reference timestamp would be a much better choice.

I strongly disagree with you.

1) How does somebody know when the reference timestamp is a reference
timestamp and when it's an offset?  Whether or not the reference
timestamp in its current form is sufficiently useful is a different
discussion.  But we should not "hijack" it without a compelling reason.

2) How is this easily visible from ntpq?

We're talking about making sure things work when things can go sideways
in a major way, about once every 2 years' time, over a period of about
24 hours.  Let's make finding these problems as quick and easy as
possible.

> > > - The refid will conflict with 1/256 of refids based on IPv6. Even if
> > >   the IPv6 refid draft that shrinks the space for IPv6 refids to 24
> > >   bits is accepted, it will take some time before it's used.
> > 
> > Only for client mode associations at the ~S3 level, that do not choose
> > to implement any of the other proposals around I-Do and refids.
> 
> That includes all old implementations, right? I.e. the target of the
> proposal?

Yes.  And beyond that...

First, I'm not sure I buy the 1/256 collision thing.  How is this not a 1
in 4B chance of collision that would only happen on 1 poll exchange?

If it does happen on 1 poll exchange who cares?  The protocol is robust
enough to handle 1 ignored sample.  Also see above about how a pure
client will never need timing loop detection.

> > What do you propose as an alternative for servers that want to offer
> > smeared time to clients?
> 
> If you need to see the fact that the server is leap smearing in the
> ntpq output in the refid field, pick a constant value for refid and
> don't encode the offset. That's what I did in chrony.

What refid value did you choose?

What happens when you have different servers offering different
applications of the leap smear?  How can you tell what they are doing?

> > > draft-stenn-ntp-suggest-refid-00
> > > - Again, the "required MAC" bit in the field type doesn't seem useful.
> > 
> > Again, what I wrote above.  The bit says "MAC OPTIONAL", and is
> > backward-compatible.
> 
> Ok, sorry for the confusion.
> 
> > > - I'd suggest to use all bits of the refid (not fix the first octet to
> > >   0xfd) to make collisions less likely.
> > 
> > Your suggestion is backwards-incompatible.  We have already seen reports
> > of the IPv6 hash returing a value that matches the IPv4 address of a
> > *different IPv4 host on the same network as the IPv6 host*.
> 
> But the same thing is happening in IPv6-only networks (and you want to
> make that problem even more common). The users just need to know the
> refid is not an IPv4 address.

No, the primary purpose of the refid is for 1-degree loop detection.

If folks want to know about an upstream server and they have
authorization to ask, they can issue a mode 6 request and see what the
source address is for that association.

If your local policy allows for this, great.  But it's unreasonable to
expect others to conform to your policy choices.

The security folks are pushing hard to limit access to this sort of
information.

People who do a lousy job of upgrading their software can expect
problems caused by running outdated software.

> > Refids are there for 1-degree loop detection, not "who is my upstream
> > server".
> 
> I disagree. Yes, the main purpose is prevention of loops, but up to
> now matching refids of two servers indicated they used the same
> source. That is a useful information.

And dangerous.  So if you want a local policy that allows it, that's
your choice.  Again, it's inapproprate for you to dictate that policy
for others.

Note that more and more folks are making this harder and harder to do.
More to the point, they DO NOT WANT arbitrary folks to know where they
are getting their time from. It's a security thing.

> > The primary reason for the refid is to detect degree-1 timing loops.
> 
> Ok, so preventing loops between two peers is important, but between
> three and more peers it is not?

Yes.

It may be that larger loops are a problem too, but in those cases it may
be that there are other, earlier problems.

Was it you who mentioned that you saw a 3-system loop, and that loop was
on systems that were using neither orphan mode nor local refclock?  If
that's the case, then please show how increasing the protocol complexity
(including a security analysis) to detect these loops is worth the cost.
Why just not fix the configuration so this doesn't happen?  Why didn't
your systems monitoring catch this when the stratum of your servers went
out-of-spec?

H
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg