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

[Robert Sparks <[e-mail]>]

On 1/6/16 2:31 AM, Karen Elisabeth Egede Nielsen wrote:
> Hi Robert,
>
> Thanks a lot for your comments.
> Please find feedback inline below.
>
> BR, Karen
>
>> -----Original Message-----
>> From: Robert Sparks [mailto:[e-mail]]
>> Sent: 18. december 2015 21:11
>> To: [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Secdir review: draft-ietf-tsvwg-sctp-failover-14
>>
>> 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?
> [Karen Elisabeth Egede Nielsen] The motivation for including the statements
> is to motivate the SHOULD statements (and to qualify the usage of SHOULD
> opposed to MUST).
> We have understood that such clarification was desirable (?).
>
> However for clarity in the specification we would be
> very happy to follow your guidance and remove the MAY paragraphs in section
> 3.2 and in section 4.
> We would however not like to use MUSTs.
>
> Would this action address your concerns ?
The document should provide explanation when using a SHOULD to let 
implementers know what circumstances warrant not following the SHOULD. 
What are the risks?

In this particular case, you're saying "The implementation SHOULD do 
this standard thing, but it MAY go do some nonstandard thing". That does 
not make sense.

_WHY_ do you not want to use MUSTs? If its only so that someone can go 
do non-standard things, say MUST. Some implementations do proprietary 
things all the time - they're just not working in a standardized way. If 
its because you think some other document will come along later and 
define a different, but still standardized behavior, use MUST and have 
that document update this one when the time comes.
>
>
>
>> 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).
>>
> [Karen Elisabeth Egede Nielsen] The reason A does not use a SHOULD is
> because the RFC4960 text does not use a capital SHOULD.
Because 4960 is (implicitly) saying MUST. If you implement 4960, you do 
what 6.4.1 says. I think you're pointing to the "should try to send" 
inside 6.4.1 - you are not making the same statement in this document.

As this sentence is written, this extension to SCTP says the 
implementation SHOULD follow the SCTP spec, which does not make sense. 
My preference would be that you remove B (as argued above), and simply 
say "When choosing amng multiple destination addresses in active state 
an SCTP sender will follow the guiding principles in section 6.4.1 of 
[RFC4960] of choosing most divergent source-destination pairs..."

> But perhaps we could
> use
> a capital SHOULD in SCTP-PF even if we are referring to text that uses a
> non-capital should in RC4960 ?
>
>> 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.
>>
>>
> [Karen Elisabeth Egede Nielsen]
> Thanks.
I've responded to the instances below inline, but please note that I did 
not provide an exhaustive list - these were examples. Please look 
through the rest of the document for other opportunities to simplify the 
text.
>
> #1: Compromisation/compromise:
>
> We could use “lower/lowering off/decrease” to be more precise.
>
> Would you think this would resolve your concern ?
Yes, you're on the right track.
>
> #2: Exceed of which:
>
> The PFMR defines
>          the new intermediate PF threshold on the destination address
>          error counter at exceed of which the destination address is
>          classified as PF.
>
> We can reformulate to:
>
> The PFMR defines
>          the new intermediate PF threshold on the destination address
>          error counter. When this threshold is exceeded, the destination
> address is
>          classified as PF.
>
> Would you think this would resolve your concern ?
yes
>
> #3: Failover to deploy:
>
> i  When there is outbound data to send and the destination
>             address presently used for data transmission is in PF state,
>             the sender SHOULD choose a destination address in active
>             state, if one exists, and failover to deploy this destination
>             address for data transmission.
>
> We can reformulate:
>
> i  When there is outbound data to send and the destination
>             address presently used for data transmission is in PF state,
>             the sender SHOULD choose a destination address in active
>             state, if one exists and deploy this destination
>             address for data transmission.
>
> Would you think this would resolve your concern ?
instead of 'deploy' consider saying 'use'?
>
> #4: unequivocally information:
>
> This would go away if we removed the MAY statement as suggested above.
ack.
>
>>
>>
>>