Skip to main content

Telechat Review of draft-ietf-teas-gmpls-scsi-03
review-ietf-teas-gmpls-scsi-03-secdir-telechat-wouters-2017-07-31-00

Request Review of draft-ietf-teas-gmpls-scsi
Requested revision No specific revision (document currently at 04)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2017-08-01
Requested 2017-06-29
Authors Daniele Ceccarelli , Lou Berger
I-D last updated 2017-07-31
Completed reviews Rtgdir Last Call review of -02 by Thomas H. Clausen (diff)
Secdir Telechat review of -03 by Paul Wouters (diff)
Genart Last Call review of -03 by Robert Sparks (diff)
Opsdir Last Call review of -03 by Qin Wu (diff)
Assignment Reviewer Paul Wouters
State Completed
Request Telechat review on draft-ietf-teas-gmpls-scsi by Security Area Directorate Assigned
Reviewed revision 03 (document currently at 04)
Result Has issues
Completed 2017-07-31
review-ietf-teas-gmpls-scsi-03-secdir-telechat-wouters-2017-07-31-00
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.