Subject: [karp] Review of ...karp-mrkmp-01

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 31 Mar 2011 23:55:17 -0700

eview-gregory-draft-hartman-karp-mrkmp-01

Review by Gregory Lebovitz

2011-03-31

This review covers Abstract, sections 1, 2, 7, 8,

(a review of sections 3 & 9 will be sent later, in a few days. Sections 4-6
will be reviewed once filled out)

Suggest we simplify the name to MaRK, but still call it "Multicast Router
Key Management Protocol". Just a marketing thing. (You'll notice "IKE" did a
lot better than "ISAKMP"). To "test it out" I refer to mrkmp as "MaRK"
through the rest of the review. Let me know if you all like it.

1.1 - time for beginning to fill this section out?

1.3 - since we are talking about the use of IKEv2, where Phase 1 and Phase 2
have been replaced by "Parent SA" and "Child SA", ought we conform to that
terminology?

Do we talk anywhere in this doc about scope of this design in the context of
the overall framework (which has been pretty much killed now)? Specifically,
this spec is to be used on a single broadcast domain / link / NBMA segment.
Each such segment will have it's own MaRK going on. A segment can be as
small as two routers, or as large as N routers, such that the two-router
case is simply a specific usage of the same mechanism, and thus solves the
multicasting routing protocols case as well as the unicasting protocols'
case.

And we'll need to talk about, but not solve, the case of changing keys on
GCKS's across a large network, where there may be hundreds (thousands?) of
GCKS's.  We'll want to do this so that people get the context clear. We
don't want to rathole on it now, though.

I volunteer to author the text for a section that accomplishes my last two
paragraphs.

2.1 Peer Key Mgmt Key: point out that this is pair-wise unique?

  KEK - is the "message encrypted in a previous KEK" the IKEv2 REKEY message
exchange? If so, can we simply say that?

  Protocol Master Key  - add: "This key is distinguished from the 'transport
key' (see next) in that this Protocol Master Key may be used in a
cryptographic operation in order to derive a specific transport key.

  transport key: s/challenging with this architecture/challenging with this
design/

 I really like the way you've clearly and succinctly laid out the difference
between the different key types. A graphic would do WONDERS for helping
people to quickly grasp the differences between these keys. Perhaps a table
would also help. Maybe something where the rows are the types of keys and
the columns are thinks like "KMP usage vs RP usage," "bootstrapping vs
traffic," "Group vs Pair-wise vs Both," and "other" for comment or
clarification.

2.1.1 - "provide both integrity and confidentiality" - throughout the
document it looks like you include authentication in the word "integrity"?
Maybe we should explicitly state this upfront, and explain why? Do we care
about non-repudiation?

?? expiration time measure in clicks from when set? Absolute clock time?

"group members need to perform a new initial exchange to the GCKS"

This is a matter of local policy configuration. Perhaps we ought to say it
this way:

  "When a KEK is retired or expires without being replaced by a new KEK
announced in the old KEK, the group members delete that KEK. Unless local
policy configuration dictates otherwise, the group member will perform a new
initial exchange to the GCKS in order to establish a new KEK."

  The way described in the text I offered is a little more IKEv2-like.

2.1.2 - in the case of separate protocol master key and traffic key, where
you propose a nonce exchange, is the nonce exchange protected?

   After a lot of work on IKE, IKEv2, SSH and TCP-AO, I STRONGLY favor the
second model, the separation of proto master key and traffic key.

2.2 - "As a consequence of such cases, an individual GCKS electing solution
within MRKMP is preferable."

For the sake of testing the hypothesis, I'd like to see someone try to come
up with a counter argument to this and see if it is at all convincing. I
think I agree with your stated hypothesis, but I'd like others closer to
routing protocol development to try it.

We may also want to describe the chicken and egg issue here:  we are trying
to elect someone to be the GCKS for the purpose of authentication of each
peer, but we can't do that until we authenticate each peer. And then we
would want to discuss at a high level how the design addresses that. If you
think this would be helpful to address in the overview here, then I could
write text to accomplish it.

2.3 "Unicast MRKMP P messages"  - drop the "P" ?

  - again, here you use "integrity" to also include per-packet
"authentication". See my comment above.

 - "While routing security does not typically require confidentiality, the
key management protocol does because keys are exchanged and these must be
protected."  - great sentence, and well placed. I could see a lot of
non-security people being confused without this point. Good job!!

 "Other mechanisms may be added as a future extension."

  why wouldn't we add in the use of simple asymmetric keying mechanisms
here, like Self-signed cert, or raw asymetric key? As you may recall, I'm
very in favor of the use of self-signed certs in this application, since the
operators all use them already for SSH'ing to the boxes. It's really no more
complex than a strong PSK, operationally, but provides far more value. I
propose we add at least self-signed cert with manual fingerprint
verification to the list in the first spec.

2.4

 "XXX we need to discuss group naming--if MRKMP is limited to a subnet this
may be as simple as saying that initiator wants to join the OSPF group or
the IS-IS group."

  why wouldn't we use a group identifier? This would provide us with
extensibility, prevent ambiguous situations in large routers with many
interfaces in adjacent segments/links, etc. My gut tells me having an
explicit group identifier is just more clean. I would guess that only 4 bits
would be necessary, but we could make it 8 bits, just in case.

"Once membership in a group is established, resources are not required to
maintain the unicast association with the GCKS."

  In testing this hypothesis I came up with one reason we may want it:
liveness detection. We would want a liveness check to be auth'd / integrity
checked per packet. I could see this being very important to ops and
management. Thoughts?

"A member of a group can also use the unicast exchange to request a GCKS to
change the protocol master key because that group has exhausted its
available sequence space."

  wouldn't the GCKS itself already know if / when the available sequence
space had been exhausted? If so, wouldn't it simply init the new key process
well prior to the exhaustion?

I really like how the document is organized with an overview of the major
parts, so one can see the whole protocol in context more quickly, and then
deep dives into each part in more detail. Well done!!

7.

 7.1

 7.2 - given multiple senders on (potentially) broadcast domain, how do we
avoid sequence number stomping, multiple senders issuing packets with the
same sequence number at the same time? - maybe we should use a concatenation
of sender + seq# ? Or maybe I missed something earlier in the draft that
explains this?

 Other things to add to 7:

 7.4  Example of a key change, walk through it for a case with 4 peers or
so.

 7.5 - Ares for monitoring and management - brainstorm what sorts of items
will be critical for actual operation.

 7.6 - peer liveness detection

 7.7 - example of a reboot case. For a GCKS. For a non-GCKS peer.

 7.8 - administrative stand-down of a GCKS. Do we have a state where a GCKS
can be administratively set to "not participating" while maintenance is
done, without having to change it's config? Such that once maintenance is
complete, it will change state back to becoming GCKS preemptively. This is
very helpful for real life operations.

8.

 8.2 This may lead to a lot of flapping. Not sure how good of an idea this
is. We should start some threads just on this topic to explore/test it some
more.

 8.3 - same with interface link down, BFD state down, etc.

Possible new section: UI Hints

 - it would be nice if all the vendors implementations treated the config
some what similarly for MaRK. For example, do you show a whole separate MaRK
config section, and leave it loosely linked in the UI to the routing
protocols? Or do you bake the MaRK config into the routing protocol UI area?
To avoid operator confusion, and assist with deployment ease between pkt
interoperable implementations, we ought to give some hints around UI in this
way.

 - we'll also want to identify profiles for crypto suites and lifetime
settings, etc. to make config MUCH easier for operators.

This is a working group operation and priorities question: How much have we
tested MaRK to see if it addresses everything we need for a KMP for BGP? I
ask this because we've all agreed previously that:

 - KMP for BGP is the Internet security highest priority for KMP work

 - we wanted to try to make a mcast capable KMP fit for OSPF and ISIS, and
then use the two-peer case of it for BGP to see if we could in fact use one?

At what point are we certain enough of the validity of something like MaRK
for the mast case that we can slow efforts there and shift to
validation/verification for BGP?

<eof>

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks