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

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 6 Jan 2016 09:31:00 +0100

Hi Robert,

Thanks a lot for your comments.
Please find feedback inline below.

BR, Karen

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: 18. december 2015 21:11
> To: [email-masked]; [email-masked];
> [email-masked]
> 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 ?

> 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. 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.

#1: Compromisation/compromise:

We could use “lower/lowering off/decrease” to be more precise.

Would you think this would resolve your concern ?

#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 ?

#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 ?

#4: unequivocally information:

This would go away if we removed the MAY statement as suggested above.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 6 Jan 2016 09:33:32 -0600

> 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.
> 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
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.
> Would you think this would resolve your concern ?
Yes, you're on the right track.
> Would you think this would resolve your concern ?
yes
> Would you think this would resolve your concern ?
instead of 'deploy' consider saying 'use'?
> This would go away if we removed the MAY statement as suggested above.
ack.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 7 Jan 2016 00:33:36 -0800

Hi Robert,

On Wed, Jan 6, 2016 at 7:33 AM, Robert Sparks <[email-masked]> wrote:

> 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.

With regard to Section 3.2 and Section 4 case you mentioned, both cases
have several possible destinations to send data.
We provide rules to pick a destination, but it might not be the best one as
the knowledge SCTP stack can have is limited. (so, this might be a risk)
So, If users can leverage external knowledge, we tried to allow them to
override the rules. But, I think we don't need to standardize this part as
you point out. Removing it is fine for me.

Thanks,
--
Yoshi