Subject: Re: [karp] Operations Directorate Review of draft-ietf-karp-design-guide-03

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Sep 2011 13:40:51 -0400

Well, changing hats, this appears to be a new requirement.
It does not appear in the requirements document.
It has not, up till now, been agreed by the working groups.
And we are a bit short of time.

If other folks in the WG think Michael is right about this issue, and 
that it should appear in the design guidelines document, please speak up 
now.

Yours,
Joel M. Halpern

PS: Getting the security right for such a verification capability 
strikes me personally as rather challenging.

On 9/21/2011 1:11 PM, Michael Sneed wrote:
> I think you can argue that it is out of scope, and that such concerns
> belong at the implementation level or in a management document. But I
> also think that operations folks need to be able to confirm that key
> management is functioning as expected, apart from whether or not the
> endpoints are able to communicate. If authentication fails, why? Can it
> be verified that fresh keys are in use after a key employee leaves? etc.
>
>  > Date: Wed, 21 Sep 2011 10:56:57 -0400
>  > From: [email-masked]
>  > To: [email-masked]
>  > CC: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
>  > Subject: Re: Operations Directorate Review of
> draft-ietf-karp-design-guide-03
>  >
>  > Speaking personally, I am not sure that what you describe is desirable
>  > or falls within KARP scope.
>  >
>  > For example, one can easily argue that the problem is "detectable" if
>  > the devices log authentication failures on association attempts. Which
>  > they do.
>  > Presumably, the KMPs themselves will detect actual protocol violations
>  > of those protocols. I would not call such detection out as a separate
>  > work item.
>  >
>  > And I certainly would not want a mechanism that reported the actual keys
>  > back for validation, since that would induce weaknesses in the system.
>  >
>  > So I am not at all clear on what can be added to the design guidelines
>  > document.
>  >
>  > Yours,
>  > Joel
>  >
>  > On 9/21/2011 7:30 AM, Michael Sneed wrote:
>  > > Hi Manav,
>  > >
>  > > That is largely my concern. If keying doesn't work, then the part
> of the
>  > > protocol protected by the key either doesn't work (eg. the peers are
>  > > operating with different key generations), or possibly isn't secure
> (eg.
>  > > a rekey did not take place on schedule). Depending on the KMP in use
>  > > there might be a number of ways this could happen, and it just
> seemed to
>  > > me that it would be worthwhile to address that this should be
>  > > recoverable, detectable, and debuggable.
>  > >
>  > >
>  > > From: [email-masked]
>  > > To: [email-masked]; [email-masked]
>  > > CC: [email-masked]; [email-masked]
>  > > Date: Wed, 21 Sep 2011 09:57:57 +0530
>  > > Subject: RE: Operations Directorate Review of
>  > > draft-ietf-karp-design-guide-03
>  > >
>  > > Hi Michael,
>  > > Can you elaborate on what you mean by "wrong key can have negative
>  > > consequences"? For a routing protocol, a wrong key would simply result
>  > > in the adjacency not coming up. Besides this, i cant see what else can
>  > > go wrong.
>  > > Cheers, Manav
>  > >
>  > > *From:* Michael Sneed [mailto:[email-masked]]
>  > > *Sent:* Tuesday, September 20, 2011 5:03 PM
>  > > *To:* ops-dir
>  > > *Cc:* [email-masked]; Bhatia, Manav (Manav)
>  > > *Subject:* Operations Directorate Review of
>  > > draft-ietf-karp-design-guide-03
>  > >
>  > > I have performed a review of draft-ietf-karp-design-guide-03 on
>  > > behalf of the Operations Directorate.
>  > > The document is intended for Informational status, and describes a
>  > > framework and design guidelines for key management targeted at
>  > > protection of routing protocols.
>  > >
>  > > The document does a good job of covering most of the areas of
>  > > operational concern in this area. The only subject that I did not
>  > > see mentioned was prevention and recovery from miskeys.
>  > > Since a failed key delivery or delivery of the wrong key can have
>  > > negative consequences for the protected protocol this could be an
>  > > important concern.
>  > >
>  > > Other than this point I found no operational issues with this document.
>  > >