[secdir] SECDIR review of draft-ietf-trill-esadi-07

Phillip Hallam-Baker <hallam@gmail.com> Thu, 24 April 2014 15:52 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FDB1A00E1 for <secdir@ietfa.amsl.com>; Thu, 24 Apr 2014 08:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 rB3JlMZXLVR3 for <secdir@ietfa.amsl.com>; Thu, 24 Apr 2014 08:52:23 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 30EE01A02CC for <secdir@ietf.org>; Thu, 24 Apr 2014 08:52:22 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id pv20so2137165lab.24 for <secdir@ietf.org>; Thu, 24 Apr 2014 08:52:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cyr7wxacSNJS8UlS9MN4eKNX/XhKbP0ADyv79d2rq/8=; b=mE/+FkG0c/CSjICySZ/xngUXgdDhR1z8hsv4IyVrzBLzrdvvUoyYiPEG1x8XdMxt+Y g5E5g+4PxbA96gzVL2DGEsIppTXbM5aoHMGyxQ7dVlqY//66lcRb8bfkPvzCmgGOLA8U x7AdQgG5Zm/wA596q4dvjAJI+actInWGmXZog7Oeu+F4aycS9JODnQsgyFX6ls2td9fj 7HINbeT6aJiQnVGzZo94qVT78Wex1+/1NLjX2jPsl0svOegt9p0/bFtnVO9JdLXEucWf +b40QYi65RcF7DqJwjsdE7iTOv8/Gg90AUJoJ9nz/aueRI600UREdMxEvyDzvqIpIL5Q M0IQ==
MIME-Version: 1.0
X-Received: by 10.112.241.73 with SMTP id wg9mr1680703lbc.48.1398354736527; Thu, 24 Apr 2014 08:52:16 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Thu, 24 Apr 2014 08:52:15 -0700 (PDT)
Date: Thu, 24 Apr 2014 11:52:15 -0400
Message-ID: <CAMm+LwgcA98LiubRSOgEAFSgXyWzT_rk-WyriY_SXq8AMBim3g@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-trill-esadi.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KWwtNS61COz6jCbrzPL3A0WIDfU
Subject: [secdir] SECDIR review of draft-ietf-trill-esadi-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 24 Apr 2014 15:52:25 -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.


This document is describing extensions to a routing infrastructure. As
such the only security properties that are reasonably achievable
without inappropriate assumptions such as trustworthy routing nodes is
to assure continuity of service. We should assume that authentication
and confidentiality of the message content are assured via some
end-to-end means where the ends are the source and destination of the
messages.

[It would be rather useful if the IAB would draft a document that
would state what security properties are expected at which level]


ESADI does provide for improved service assurances by allowing the
authentication of nodes.

What is less clear is how this authentication is leveraged Section 5.1
suggests that authenticating endpoints permits higher confidence to be
built up. if end nodes are authenticated to their MAC address. But
this authentication only has value if there is a chain of custody
authentication to the relying party. Section 6.2 describes a mechanism
that might be relevant here. A pointer would be helpful.




-- 
Website: http://hallambaker.com/