Subject: [karp] Review of design-guide-02

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

Karp'ies,

Below you will see mostly small editorial nits. However, a few more
substantive comments exist and should be addressed before moving to AD
approval. In each case I have proposed new text. If there are no issues,
Manav and I will edit the document per the suggestions below.

I'll "see you" remotely in in a few hours at the session.

 - Gregory.

========

Comments on karp-design-guide-02

Gregory Lebovitz

2011.03.30

 "Abstract

     -- snip --

      This document is one of a series concerned with defining a

      roadmap of protocol specification work for the use of modern

      cryptographic mechanisms and algorithms for message

      authentication in routing protocols.  In particular, it defines

      the framework for a key management protocol that may be used to

      create and manage session keys for message authentication and

      integrity.  "

    -- snip --

Is this last sentence true of this document? I think this is text rot from
earlier versions of the document where the framework was also included in
the body. I think it ought to be removed

Suggested new text:

"In particular, it categorizes existing routing protocols into logical
groups for analysis and describes a process by which design teams are to
review and work on updating those routing protocols, including security
considerations. One specific design consideration is the for the future
existence of an automated Key Management Protocol."

3.1, para 3

"Many routers have the ability to be remotely managed over the

      SSH [RFC4252] and [RFC4253]."

New:   … managed over SSH…

 "As such, they will also have the

      ability to generate and store an asymmetric key pair, because

      this is the commonly used method that users authenticate the

      SSH service when connecting to the router for management

      sessions."

Awkward wording. New:

 Therefore, one can be sure these routers have the ability to generate and
store an asymmetric key pair, because that capability is in use today for
the ssh authentication.

3.1 para 4

 s/Once asymmetric key pair/Once an asymmetric key pair/

 s/for the identity proof/for its identity proof/

3.2 title s/Keys Life Cycle/Keys' Life Cycle/

 para 1 - s/using the key chains/using key chains/

 add after "… leaves the company.":

   In the case of a terminated administrator, the security properties of one
key are the same as those of a key chain.

4.1 para 1 - reads very awkwardly, and shortcuts things explained much more
clearly a few paragraphs later. Remove the text explaining the separation of
KMP from Routing Protocol, and leave it for point 2 a few paragraphs later.
Re-write as:

 The authentication mechanism overhaul for any base routing protocol will be
accomplished in two phases. Phase one will address the manual key management
mechanism already in existence for the protocol, updating it to support
modern cryptographic practices. Phase two will then provide the automated
key management protocol and specifications for how the base protocol will
use it. In this process we will crawl, walk, and then run. We will deliver
incremental improvements in the security of these authentication mechanisms
to the operators so that the changes are readily deployable.

para 2: s/In other words, simplicity and deployability are keys to
success./Simplicity and deployability are keys to success./

in the paragraph starting with "The framework…" we reference the
ietf-karp-framework document, which the ADs and Chairs want killed. So we
need to strike it here. Instead, summarize with this text:

It is useful to cleanly separate the key management protocol from the
routing transport subsystem. The routing transport subsystem will be
oblivious (for the most part) to how the keys are derived, exchanged, and
acquired, and care only that a key and usage parameters are available to it.
For example, a routing protocol implementation could have a configuration
switch that makes a request/call to a separate security module, asking for
the "KARP parameters." Being separate, this security module could be written
and maintained by different developers, perhaps even a security team. The
KMP module could also potentially be leveraged by other routing protocols.
Of course these are implementation details; the example is offered merely to
fill out the vision of a framework where a routing protocol and KMP are
separate, but working together within the system.

4.2

 Characterize the RP

  s/Does it needs significant/Does it need significant/

 Define Optimal State

  s/usage and format to contain to modern/usage and format to contain
modern/

 Gap Analysis

  s/to its optimal state/to its optimal state for Phase 1/

 KMP Analysis

  s/List the requirements that this Routing Protocol has for being able to
be use in conjunctions with a KMP. Define the optimal state and check how
easily it can be decoupled with the KMP./List the requirements for using
this Routing Protocol in conjunctions with a KMP. Define the optimal state,
keeping in mind the architectural goal that the routing protocol be
decoupled from the KMP./

 Define, Assign, Design

  new text, in light of the fact that we don't have a framework document
anymore:

   …These will be the attributes that the Routing Protocol and KMP will need
to trade in order to bootstrap the session keys to the Routing Protocol.
[delete last paragraph that was in this section]

5. OSPF…

  s/peering messages includes OSPF/peering messages include OSPF/

6. Gap Analysis

  para 4: re-write paragraph as follows, for read-ability:

When doing the gap analysis the team must first identify the elements

      of each routing protocol to protect. In the case of

      protocols riding directly atop IP, consider if the IP

      header and the protocol headers ought to be protected. For those that
sit atop TCP, consider if both the TCP header and the protocol payload ought
to be covered by the authentication operation.

      There is value in protecting the IP header and the TCP

      header if the routing protocols rely on these headers (for example,
for identifying the neighbor that

      originated the packet).

 para 5:

   s/Then there will be a set of Cryptography requirements that we might
want to look at./Next, the team will consider cryptographic requirements./

   s/MUST be at least on/MUST be at least one/

   delete: The design teams should look for this for the protocol

      that they are working on.

 para 8: s/so that it does not get influenced by packets loss and
reordering./so that the exchange is not negatively impacted by packet loss
or re-ordering./

 para 9: s/that their protocols authentication/that their protocol's
authentication/

 para 10: this statement is unclear. What does it mean to "affect the
functioning of the routing protocol"? The example given doesn't help the
reader to make that definition. Pls try and explain it better here, on
email, and then we can figure out text to support it.

2nd-to-last para of 6:

 s/This means that the designers must work

      on this aspect of authentication mechanism for the routing

      protocol that they are working on./Design teams must address the need
for incremental deployment./

   That sentence will not be possible in some cases. What's more important
is that implementations can run both the old and the new in parallel, and
have a security policy to handle the transition case. Suggested new text:

   As such, the new mechanisms must either be backward compatible in the
message formatting, transmission and processing of routing information, or
implementations must be instructed to support running both the old and the
new mechanisms simultaneously with local security policy to define when one,
the other, or both are allowed, and in what preference.

Sect 7

7.1

 para 2: s/The burden for doing so is understandable much higher/The burden
for using unique keys per pair of peers is understandably higher/

 para 3, last sentence: s/intra-connection replay
protection./intra-connection replay protection will also be achieved./

7.4

para 8: s/The desired end goal for KARP WG is develop a strong peer-to-

      peer KMP as an Out-of-and external Key Management protocol is

      out of scope./The desired end goal for KARP WG is develop a strong
peer-to-peer KMP. An Out-of-Band external Key Management protocol is

      out of scope./

para 9: s/inside the protocol itself./inside the routing protocol itself./

<eof>
-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks