[secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-06

Radia Perlman <radiaperlman@gmail.com> Sun, 14 August 2016 00:07 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9E12D60E; Sat, 13 Aug 2016 17:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4oG6CJImAOk; Sat, 13 Aug 2016 17:07:41 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1BF12B006; Sat, 13 Aug 2016 17:07:41 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id f189so24806406oig.3; Sat, 13 Aug 2016 17:07:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Ws7yPmarnJ8DlH48fyRKMJZEyQ1Hvweu4LijQaCSp3M=; b=s2aP5oucpn9MDJKQx/G+leWKSfXvfi45nUejvfNw0Cr8IxnOUmAW+7I19iLDU6wGCv 69nmGiaiWLXCH2IXlphCNgqnfgK1u7HocZ7P7m/PZD3ELhtUWvwHxS2CWbpoqXHQRl8c SZhBH2ruMlohQGTHItKJkI5pPVhdHUS3Kl6mbshIOcvpSX5cNudKSktL1a2QfCA/bn7U +QbJKpSSKaBAOej2a7TIwRfVYt7ztrTr1F2so0sJeOG/Kt9gdecPSqJOtk1IavoZTvFs H4xqYkN2LhpnnMx2JRiazYQyvB7vKCyFepA8/x67/meBnj4323mFkc/fpyavaEWd6rBO 4gZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ws7yPmarnJ8DlH48fyRKMJZEyQ1Hvweu4LijQaCSp3M=; b=gviMTW2HWz5rlMJmnwjcG1ZZhOCS94NGZL2AcLHRqXond2sp6a1pXjEWYGMaUytIx7 7bvOHs5DuXuFehm/zapGd7yANVG3O/kJ520RHwI7rl/tTLPGR7N54xn2eUt138tN4Er2 F72OPkhEl9M5Y5yijlB9Xgy/Q1iOnM1vwN0EAZN/mAt8DMK+8McPowbV329xNClo14q0 RXoZdGm4ZY4nzbx3dRr6aaSXE4Elqs0GVZ0791sE6uYYWa3fOoIKHf7oxXhW8IoAoxAb P9mqxb1SHgwqfoNhQASHzS3zfFAA4+TRU2quQc06IFv2VuaiRCj35Wxojjv8gR8g+HGl N5BA==
X-Gm-Message-State: AEkoouv3q87UrcriBbQCkXCaKB+xtpZ00EbsNw1uIU++mTDi3/WHE4C4vKhcZHxWfONKzTs7h0MJcZMN5LtKNQ==
X-Received: by 10.202.198.78 with SMTP id w75mr11651578oif.134.1471133260509; Sat, 13 Aug 2016 17:07:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.81.227 with HTTP; Sat, 13 Aug 2016 17:07:39 -0700 (PDT)
From: Radia Perlman <radiaperlman@gmail.com>
Date: Sat, 13 Aug 2016 17:07:39 -0700
Message-ID: <CAFOuuo6+2MqD8QKzemRZ77tEzXyFr+Ja-D8U7woXEq0LKRcngQ@mail.gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a11c17da668f8180539fce746"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SWfgBWa0zqeIXeoBdbaL89f571c>
Subject: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Aug 2016 00:07:43 -0000

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security area
directors.

Document editors and WG chairs should treat these comments just like any
other last call comments.


The document is about the security requirements between a management
station (what I assume a "I2RS client" is) and the agent on a "routing
system". These include mutual authentication, transport security, atomicity.


The document is well-written and ready, with nits.


I haven't been following this WG, so apologies for perhaps not getting the
terminology, though it might be better if every document were self
contained, in defining terms, or pointing to a different document where all
the terms are defined.


The meaning of the  term in the spec  "routing system" is not obvious to
me. I'm assuming it means not only routers but anything that looks at layer
3 such as load splitters and hypervisors, is that correct? Maybe the term
is defined in a different document? If not, a clarifying sentence would be
appreciated by readers.


In section "I2RS multi-message atomicity"

"this is not supported in order to simply the first version of I2RS"

should be "simplify"


"If insecure transport is used, then confidentiality and integrity
cannot be achieved"

That statement, as a sweeping statement, isn't true, since, for
instance, Ethernet does not provide any confidentiality and integrity,
but protocols can achieve confidentiality and integrity by doing it
themselves.  So perhaps the statement should be softened to say
something like "I2RS does not itself provide confidentiality and
integrity, so it depends on running over a secure Transport that
provides these features".


"All I2RS clients and I2RS agents MUST have an identity, and at least
one unique identifier that uniquely identifies each party in the I2RS
protocol context."


This might be overly restrictive.  You might want several I2RS clients
acting as instances of a single identity, in which case, they might
all share the same identity.


" SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF
      or private) will distribute or load identifiers so that the I2RS
      client/agent has these identifiers prior to the I2RS protocol
      establishing a connection between I2RS client and I2RS agent."


Instead of "distribute or load", perhaps "configure" would be clearer?
 At any rate, I don't know the difference between "distribute" and
"load".


Radia