Subject: [karp] Comments on draft-ietf-karp-crypto-tables

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Feb 2012 19:24:52 -0500

Here are some comments on the crypto draft.

Below I talk about normal form and first normal form a lot.  These are
database comments. The wikipedia page is not the worst description
ever if you are unfamiliar with the concepts.  I want to stress that I
don't think we should blindly assume normal form (particularly say
3nf) is good in an information model.  In fact, I think that the ideal
result for this table will be somewhat denormalized.  However I've
pointed out cases below where I believe the specific denormalization
of the table gets in the way of a quality management/operations
experience.  I don't think "this isn't 1st normal form," is a valid
objection. I do think "this isn't 1st normal form in way x which
causes problems y and z," may be a valid objection.

>   To accommodate manual key management, then formatting of the fields
>      has been purposefully chosen to allow updates with a plain text
>         editor.

I think this text should be removed and a plain-text editor is not the
format I'd expect will be common for updates.  Seems to be that CLI
operation, netconf schemas or something like XML will be more common,
which CLI operation hugely dominating for manual key management.
(Often CLI driven by scripts)

Updating in text editors has siginificant operational issues. For example it's very eeasy to express invalid combinations of configuration in a manner that a CLI would detect.

General: hexadecimal integers.  You specify that the integers are
hex. Conceptual integers don't seem like they should have a base.  It
may well be that we want to have textual conventions for representing
key IDs and keys and the like in operator interfaces.  We could do
that in this document or draft-ietf-karp-ops-model.  I think hex is a
fine convention for some of these values, but I don't think it's
appropriate to mix textual conventions and conceptual data type in an
information model.

Local key ID.  In a conceptual table why is it important that the
field is 16-bits wide?  It seems like this is only desirable if it
aligns with something over the wire that is 16-bits wide or for some
other interoperability purpose.

In a information model--that is a conceptual modeel of management
information--it seems poor to have pair-wise vs group key being
determined by a bit in the key ID.  First, that means that we really
have a 15-bit range; 15-bits is even more odd than 16-bits for a
conceptual model.  However more seriously, why is it a good idea to
combine these fields? Why should the domain of this column effectively
be tuples of key type and id rather than having two columns?
Depending on which definition you take of first normal form, this
would count as a denormalization of the table, and many of the
problems that can pop up when your database in denormalized do pop up
with this example. It makes it more challenging to ask for all group keys.

It seems like a fairly bad idea to have a field whose value is sometimes unique and sometimes not.

Peer key ID: Again, it seems overly proscriptive to describe this as

I have two concerns about this field. First, it is nonsensical. The values "group" and "null" are not 16-bit integers.
Mor seriously, though, as you point out, the form of the peer key ID is dependent on the protocol that wil use it.
In a conceptual table, we should leave the form up to the protocol and not even specify whether it is an integer or name because that depends on the protocol in question.

In a file format, netconf schema, MIB or the like, we'd have to be more concrete.
But we're doing a conceptual model here.

peers: What is the conceptual format of this field?  How is it used?
This field is not in first normal form in that it's a repeated
group. That's problematic because it seems likely that multiple key
rows might share the same set of peers. By having the peers
denormalized in this manner it makes it hard to update the appropriate
set of peers.  That is, I have 3 keys shared between peers a, b, and
c. Because the peers field is denormalized it's easy to get to a state
where I have two keys with peers a, b and c and a third and fourth key
with peers a, b, c and d.

protocol-specific, kdf, kdf inputs: It seems kind of haphazard what
information is a column in the table and what information is folded
into protocol specific.
Describing protocol specific as binary also seems wrong in a information model.
One thing to think about here is whether aspects of protocol specific will need to be indexes for finding the right record.

key lifetimes: As discussed in the meeting I prefer send not before
and send not after and prefer to avoid the complexity of receive
lifetimes.  So, I'd like to object to that change made in the last
revision and visit the question of whether the WG has consensus to
make that change.
The document seems overly proscriptive for the textual convention of a date for a conceptual model.

I'd also like to bring up the issues raised in section 3 of
draft-ietf-karp-ops-model.  The interfaces, peers model of describing
which key to work seems rather specific to a protocol.  Some of the
issues with this model are discussed in section 3 of
draft-ietf-karp-ops-model.

I suspect that after we discuss my concerns with section 2 I'll have
some concerns with section 3, but it will probably be easier to
address them later.