Re: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational

[Uma Chunduri <[e-mail]>]

Dear Authors,

I happened to read this  document again after a long time and it's changed quite a bit and in the current form it's certainly  relevant for Routing operations folk. 
You touched upon scope of keys to, configuration using key tables, various key types being used (KARP scope) and handling faults. All are very useful.

First I would share my opinion on the suggestions asked for:

3.2 key expiration -- (my comments for new suggested text)

Though it's fair from operations perspective, obviously not good for security perspective. Probably situation with key roll over for RP's could improve with Key management protocols usage (with in built soft key rollover times etc..). In that spirit you can at best use a "MAY"

5. Grouping peers - 
Yes, useful and it's reasonable.

6.1 - 
Very important aspect and not aware of any opsec document which touches this aspect.


Other not so significant comments I have:
-----------------------------------------

1. Section 1 - Page 3

   "This document also gives recommendations for how management and
   operations.."
    s/operations/operational

2. Section 3.2
     - Currently text mainly focus on manual deployments.
     - Section 3.3 talks different aspect with KMPs not the rollover
     - Hence, this section may need to consider both manual keys and keys being populated by the KMP; 
       where KMP  (peer2peer or group) ensures keys are properly replenished before the old keys expiry.

3. Section 4 (last 3 paragraphs)
    - It's better if  the scope of the keys talked about differentiates for RPs and KMPs in separate sections.
      I am indicating this because, certificates and other form of authentication methods are not directly applicable to RPs, with in KARP scope.

4. Section 4.2 and 4.3
    - These are not directly applicable to RPs but critical for KMPs.
      If you can restructure section 4, it benefits immensely for the routing developers and operator community.

5. Section 6.2
   "Faults may interact with operational practice in at least two ways.
   First, security solutions may introduce faults.  For example if
   certificates expire in a PKI, previous adjacencies may no longer
   form.  Operational practice will require a way of repairing these
   errors.  This may end up being very similar to repairing other faults
   that can partition a network."

   Need to indicate this as KMP related issue rather than RP issue as far as KARP is concerned.


--
Uma C.