[secdir] Secdir review: draft-ietf-tsvwg-sctp-failover-14

Robert Sparks <rjsparks@nostrum.com> Fri, 18 December 2015 20:10 UTC

Return-Path: <rjsparks@nostrum.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 C64B31B3897; Fri, 18 Dec 2015 12:10:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Fk0KIj7wMUlC; Fri, 18 Dec 2015 12:10:40 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 54BC21B3883; Fri, 18 Dec 2015 12:10:40 -0800 (PST)
Received: from unnumerable.local (pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBIKAcc6043297 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 18 Dec 2015 14:10:39 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187] claimed to be unnumerable.local
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-tsvwg-sctp-failover.all@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <5674683F.30308@nostrum.com>
Date: Fri, 18 Dec 2015 14:10:39 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/kvz9CSsMVTi3VL4IXolyCTN-VB4>
Subject: [secdir] Secdir review: draft-ietf-tsvwg-sctp-failover-14
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: <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: Fri, 18 Dec 2015 20:10:41 -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.

Summary: Ready for publication as Proposed Standard but with nits that 
should be considered

This document defines a set of new SCTP sender behaviors that lead to 
quicker failover. The behaviors have an obvious security consideration 
(it is much easier for an attacker trigger failover, and potentially 
steer traffic to the most favorable of the available paths for the 
attacker's purposes). The document makes this very clear, and has a 
reasonable discussion in the Security Considerations section.

The shepherd writeup notes that what is here is widely (if partially in 
some cases) implemented and deployed.

There are a few places I suggest would benefit from more attention:

There are several places in the text that allow (MAY) the sender to 
choose not to behave in the manner this document is trying to 
standardize. See item B in section 3.2, and item C in section 4 for 
example. These seem out of place - if something is doing those things, 
you might as well say they're implementing some other unstandardized 
extension for failover. Why do you need to include these statements? 
They don't standardize whatever private "because I know better" behavior 
the endpoints they are discussing are engaging in. Consider deleting 
them, or restructuring the text to make this look less like protocol 
definition. (It's particularly odd that B in 3.2 uses MAY, but A does 
not use SHOULD).

The third paragraph of section 4 has a "does not compromise the fault 
tolerance" condition, leaving what would be considered a compromise very 
vague. Again, an endpoint choosing a different dormant state operation 
than the one you're standardizing here isn't behaving in a standard way. 
Why do you need this paragraph? If you're going to keep it, consider 
pointing to or providing more discussion on what you mean by the condition.

There are many unusual phrases used in the text. These are harder to 
read than they need to be, and will be even harder to translate. Please 
consider an editorial pass _before_ this is in the RFC Editor's hands. 
Search for "compromisation", "at exceed of which", "failover to deploy", 
and "unequivocally information" to get a feel for what I'm pointing to.