[secdir] Secdir telechat review of draft-ietf-teas-gmpls-scsi-03

Paul Wouters <paul@nohats.ca> Mon, 31 July 2017 21:12 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D28F1131CDC; Mon, 31 Jul 2017 14:12:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters <paul@nohats.ca>
To: secdir@ietf.org
Cc: draft-ietf-teas-gmpls-scsi.all@ietf.org, ietf@ietf.org, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.58.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150153554378.6396.10436130949472778994@ietfa.amsl.com>
Date: Mon, 31 Jul 2017 14:12:23 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/8mDzqacbf02YwJLJJFzSjIU7JbI>
Subject: [secdir] Secdir telechat review of draft-ietf-teas-gmpls-scsi-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 31 Jul 2017 21:12:24 -0000

Reviewer: Paul Wouters
Review result: Has Issues

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 summary of the review HAS ISSUES (might be minor)

The security considerations section only lists those considerations of
other documents it references. While that likely covers most issues, I'm
not sure it covers all issues. The introduction of this document tells us the
goal of this new "Generalized SCSI" value only in a somewhat vague way:

        [...] can be used with routing protocols that define GMPLS ISCDs,
        and any specific technology.

Since it does not explain _how_ it can be used, it is a bit difficult to
figure out what the security impact of this new field could be when it
is abused. What happens when this new field contains wrong or malicious
information?

And when I read:

        SCSI-TLVs MUST be processed in the order received and, if
        re-originated, ordering MUST be preserved.

What happens if someone maliciously re-orders these?

        Unknown SCSI-TLVs MUST be ignored

What happens when someone mangles a valid SCSI-TLV value so
it becomes ignored?

Another issue that could use clarification is the padding. It is only
said "may contain padding", but it is not specified how to pad. Prefix
with leading zeros? Append with FFs?

NITS:

        "[RFC7138] introduced a "

This reference is broken

In diagrams we tend to use "~" and not "..." to indicate variable length

I tend to use +--------+------+ rather then +-+-+-+-+-+-+

I would not explain "octets (bytes)". IETF tends to use octets as term.

"The value of the field MUST" -> "The value MUST"

corollary - A word harder for non-native english speakers

        "MAY contain a sequence of zero or more SCSI- TLVs."

MAY and "zero or more" is a little odd.