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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Thu, 07 January 2016 08:33 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560E21A87BF; Thu, 7 Jan 2016 00:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.215
X-Spam-Level: **
X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snYSjH_Xb_Yc; Thu, 7 Jan 2016 00:33:41 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1851A87AC; Thu, 7 Jan 2016 00:33:40 -0800 (PST)
Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5BC9227812A; Thu, 7 Jan 2016 17:33:38 +0900 (JST)
Received: by mail-yk0-f175.google.com with SMTP id v14so239146979ykd.3; Thu, 07 Jan 2016 00:33:38 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.129.46.208 with SMTP id u199mr74353754ywu.129.1452155616865; Thu, 07 Jan 2016 00:33:36 -0800 (PST)
Received: by 10.129.147.5 with HTTP; Thu, 7 Jan 2016 00:33:36 -0800 (PST)
In-Reply-To: <568D33CC.1010804@nostrum.com>
References: <5674683F.30308@nostrum.com> <4abd43f956e62870df92d15cb8662b36@mail.gmail.com> <568D33CC.1010804@nostrum.com>
Date: Thu, 7 Jan 2016 00:33:36 -0800
X-Gmail-Original-Message-ID: <CAO249yczqA_pqNtYd6DPtja-TJdzjtDgVD8xWEbCpSSN2M6+Zw@mail.gmail.com>
Message-ID: <CAO249yczqA_pqNtYd6DPtja-TJdzjtDgVD8xWEbCpSSN2M6+Zw@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary=001a11408592b3bdda0528ba5301
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/nsvQbioJI9Fk02xtlrDvsLiLMoU>
X-Mailman-Approved-At: Thu, 07 Jan 2016 08:00:59 -0800
Cc: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>, draft-ietf-tsvwg-sctp-failover.all@ietf.org, The IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Secdir review: draft-ietf-tsvwg-sctp-failover-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2016 08:33:43 -0000

Hi Robert,

On Wed, Jan 6, 2016 at 7:33 AM, Robert Sparks <rjsparks@nostrum.com> 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:rjsparks@nostrum.com]
>>> Sent: 18. december 2015 21:11
>>> To: secdir@ietf.org; iesg@ietf.org;
>>> draft-ietf-tsvwg-sctp-failover.all@ietf.org
>>> 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