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

[Karen Elisabeth Egede Nielsen <[e-mail]>]

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 ?



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

>
>
>
>