First NTS code

Eric S. Raymond esr at thyrsus.com
Mon Jan 28 12:19:35 UTC 2019


Hal Murray <hmurray at megapathdsl.net>:
> We should start collecting max/min/required lengths and references to where 
> that number comes from.

Agreed.  That was on my list.

> Do we want to store cookies and passwords and such in a fixed max-size array 
> or as heap allocated blobs?  In any case, we need to remember the lengths.

Depends - if they're textual we can assume a '\0' sentinel.  I'd prefer to
do that if possible, it would minimize the amount of data items to manage
and thus potential defects.

> There are lots of places where we will be passing around c2s and s2c.  Maybe 
> we need a struct for them (and lengths).

Very likely.

> You should probably add a section for global variables for the server side.  
> I'd call them nts_K and nts_I, using the names from RFC section 6
> and nts_old_K and nts_old_I

Feel free to do that.

I would, but my focus is slightly different now. While writing nts.c I
realized that the C code in ntpd is going to have to do real things with
packet extension fields.  That knocks over some dominos.

The first one to fall is that a job Daniel ducked after the Great
Refactoring has to get done.  That is unifying the old ("insane",
struct pkt) with the new ("sane", struct parsed_pkt), because only the
latter has actual support for extensions other than the MAC field.

The second to fall is that the ugly type punning around refid fields -
sometimes treated as char refid[4], sometimes as uint32_t - has to
end.  That's a prerequisite for moving everything to the parsed-packet
representation.  I have a patch ready to push for this - I'm
rechecking it now.

Then I do the rest of the spadework to unify those packet representations.

Once I get those packet representations unified, I need to write
primitives for adding exension fields to a packet and extracting them.

After *that*, it will be time to modify the ntpd config parser to
supply all the configuration info needed for the NTP client and server
sides.

The I need to write everything about ntsked except the actual packet
processing.  A baby C framework for a TCP/IP listener, basically. I'm
hoping I'll be able to swipe this from somebody else's code.

You notice I'm talking about everything but the NTS packet processing
itself.  You and James Browning and others have developed better
understanding of that than I have.  I, on the other hand, have been
more intimate with the config parser and the other bits of C
infrastructure NTS needs to use than the rest of you have.

So I'm making it my job to define the NTS code's interface to the rest
of that infrastructure, and then line up all the ducks outside nts.c
in neat rows. While that's going on, you and others can be filling in
the RFC-driven bits nts.c.  My goal for what's there now was just to
define enough of it so you guys can be productive.

> Maybe the cookie stuff should be in a separate module.

Maybe. But non sunt multiplicanda moduli sine necessitate; right now let's
bias towards keeping everything in one operating field.

> We'll also need the AEAD algorithms we support and their crypto pointers.

Agreed.

> #define NTS_COOKIES     8       /* RFC 4.1.6 */
> I'd call that MAX_COOKIES

NTS_MAX_COOKIES, please. For namespace control.  Feel free to do that.

> The client side needs:
>   c2s and s2c, and lengths
>   array of bools for which cookies are valid and another for unused.
>   an array of cookie lengths.
>   the AEAD algorithim we are using.  Probably 2 of them, the IETF number and 
> the pointer to the crypto stuff.

Right.  Again, you and James and Ian are presently better positioned to write
this stuff than I am.  Go to it.  Document your assumptions.

> The struct info needs to move from nts.c to nts.h
> We need one per server, in the peer struct.

Agreed, but I was planning to add a struct pointer member to the peer
struct exactly so that struct does not have to be exposed outside
nts.c.  I'm information-hiding; that part is my job. :-)

> Your "empty cookie string as a sentinel" doesn't work unless you allocate 
> space for the extra slot.

Eh? We know what the maximum number of cookies is. I think all we have to do
is notice which cookies are empty (have initial NUL).  But I might be wrong
about that; I'm not wedded to that representation, it's an inside-NTS thing
that belongs to whoever writes the cookie extraction code.

> nts_client_ke_request
> nts_server_ke_verify
> 
> Those are poor names considering what you have them doing in the comments.
> I would have picked nts_ke_client and nts_ke_server.

I don't care much what these are named. If you take on writing them, you get
to choose and I won't joggle your elbow without good reason.  The important
thing is to get the layering right.

> Actually, what you want at this level is nts_ke_server_start.  The actual 
> per-client server processing is internal to the server.  It calls out to 
> nts_new_cookie (8 times)

I'm going by the diagram in RFC section 4; you should notice that the
preceding comments replicate box text in that diagram.  I want to stick
with that partitioning unless there's a really good reason not to, because
it makes seeing the fit between code and RFC easier.

> The descriptions for nts_validate and nts_decorate seem fishy.  I think we 
> need separate routines for client and server.
> (that is 4 total)

Again, non sunt multiplicanda entia sine necessitate,  It's OK if these
have a guard "if (server_side)"; I lean towards preferring that because
it might make eyeball-checking the code against the RC easier.

While that preference is not written in stone, let's write some
implementation and see how it looks before leaping.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.




More information about the devel mailing list