Re: [karp] Last Call: <draft-ietf-karp-ops-model-07.txt> (Operations Model for Router Keying) to Informational RFC

Sam Hartman <hartmans-ietf@mit.edu> Mon, 29 July 2013 08:54 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A09521E808A; Mon, 29 Jul 2013 01:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jat8880m0KUy; Mon, 29 Jul 2013 01:54:26 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id DFD0421F9E3F; Mon, 29 Jul 2013 01:54:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id AB26620202; Mon, 29 Jul 2013 04:53:50 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxm_SuNIw_ti; Mon, 29 Jul 2013 04:53:49 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (dhcp-4332.meeting.ietf.org [130.129.67.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 29 Jul 2013 04:53:49 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 31E3787FB4; Mon, 29 Jul 2013 04:54:20 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: ietf@ietf.org
References: <20130729063557.22039.63212.idtracker@ietfa.amsl.com>
Date: Mon, 29 Jul 2013 04:54:20 -0400
In-Reply-To: <20130729063557.22039.63212.idtracker@ietfa.amsl.com> (The IESG's message of "Sun, 28 Jul 2013 23:35:57 -0700")
Message-ID: <tsltxjdwxtv.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: karp@ietf.org
Subject: Re: [karp] Last Call: <draft-ietf-karp-ops-model-07.txt> (Operations Model for Router Keying) to Informational RFC
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 08:54:32 -0000

Hi.

Yes I'm making a last call comment on a document I edit:-)

During discussion of another document
)(draft-ietf-karp-crypto-key-table), a routing directorate review
brought up the concern that we don't talk about time synchronization.
Without time synchronization, the wrong keys can be selected in certain
circumstances.
In some cases, time synchronization is required for replay detection,
although that is rare for routing protocols.

Those involved in the discussion of time synchronization and
draft-ietf-karp-crypto-key-table believed that draft-ietf-karp-ops-model
is a better place for a discussion of time synchronization than
draft-ietf-karp-crypto-key-table.

So, I'd like to propose the following text be added to security
considerations:

      <t>Close synchronization of time can impact the security of
      routing protocols in a number of ways.  Time is used to control
      when keys MAY bxegin being used and when they MUST NOT be used any
      longer as described in <xref
      target="i-d.ietf-karp-crypto-key-table"></xref>.  Routers need to
      have tight enough time synchronization that receivers permit a key
      to be used prior to the first use of that key or availability will
      be impacted.  If time synchronization is too loose, then a key can
      be used beyond its intended lifetime.  The Network Time Protocol
      (NTP) can be used to provide time synchronization.  For some
      protocols, time synchronization is also important for replay
      detection.