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, 07 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
- [secdir] Secdir review: draft-ietf-tsvwg-sctp-fai… Robert Sparks
- Re: [secdir] Secdir review: draft-ietf-tsvwg-sctp… Karen Elisabeth Egede Nielsen
- Re: [secdir] Secdir review: draft-ietf-tsvwg-sctp… Robert Sparks
- Re: [secdir] Secdir review: draft-ietf-tsvwg-sctp… Yoshifumi Nishida