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

Uma Chunduri <> Mon, 15 April 2013 21:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9AF321F9122 for <>; Mon, 15 Apr 2013 14:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jtUtlLZnWrij for <>; Mon, 15 Apr 2013 14:11:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 011B521F877B for <>; Mon, 15 Apr 2013 14:11:20 -0700 (PDT)
X-AuditID: c6180641-b7faf6d00000096b-1d-516c6cf814bb
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 48.24.02411.8FC6C615; Mon, 15 Apr 2013 23:11:20 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 17:11:19 -0400
From: Uma Chunduri <>
To: "" <>
Thread-Topic: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational
Thread-Index: AQHOOh3GVOMbw+XA10WKLAVvTHY5Rg==
Date: Mon, 15 Apr 2013 21:11:19 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXSPt+6PnJxAg30bpC0O3L/HbLH32xpG ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj4u6nzAUtIhU/94k2MJ7n72Lk5JAQMJFY ee4XK4QtJnHh3no2EFtI4CijxNZe8y5GLiB7OaPE3q5rYAk2AT2Jj1N/sncxcnCICERLnJsb DRJmFlCW6G7pYAGxhQXCJC5//MMMYosIhEs0zT3HCFGuJ3HrajhImEVAVeLjnctg5bwCvhI7 DpxkgVj1l1Fi5+ImsF5OgVCJ64vvMYHYjEC3fT+1hglil7jErSfzmSBuFpBYsuc8M4QtKvHy 8T+oX5Qlvs95xAJRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJG llWMHKXFqWW56UaGmxiBEXJMgs1xB+OCT5aHGKU5WJTEeUNdLwQICaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYGRbILJQLvTchpSipK3yZUfzBHTv/zzFnRk/Z6Hup0V5v/r1p3x/ZlkkYb12 ptGWG2fPf2zU2PH+rT5DrfW25/3s6+3rFC62CFg9r2yxYMl/++goe7d74QSOpZMWHG53MNhy dNHTvD1+Hbu697E0bFx8gH1ppsC9jXY6Cv0Oi6qMxI/s/XEyJESJpTgj0VCLuag4EQAUrfgs XgIAAA==
Cc: "" <>
Subject: Re: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Apr 2013 21:11:21 -0000

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

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.