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

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Dec 2015 14:10:39 -0600

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.