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

[Yoshifumi Nishida <[e-mail]>]

Hi Robert,

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

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


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