[secdir] Collision on changes for draft-ietf-soc-overload-control-14
"Vijay K. Gurbani" <vkg@bell-labs.com> Tue, 18 February 2014 19:39 UTC
Return-Path: <vkg@bell-labs.com>
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 D10181A052E; Tue, 18 Feb 2014 11:39:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 WwshxgWEFCxt; Tue, 18 Feb 2014 11:38:57 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A94DE1A050C; Tue, 18 Feb 2014 11:38:52 -0800 (PST)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1IJckjW023611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Feb 2014 13:38:46 -0600 (CST)
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s1IJcknx006303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Feb 2014 13:38:46 -0600
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s1IJcjPT007397; Tue, 18 Feb 2014 13:38:45 -0600 (CST)
Message-ID: <5303B709.20407@bell-labs.com>
Date: Tue, 18 Feb 2014 13:39:53 -0600
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, "jsalowey@cisco.com" <jsalowey@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/OgUmumw-uMsos_VF1BcLwTUVh4w
Cc: "draft-ietf-soc-overload-control@tools.ietf.org" <draft-ietf-soc-overload-control@tools.ietf.org>, "soc-chairs@tools.ietf.org" <soc-chairs@tools.ietf.org>, IESG IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: [secdir] Collision on changes for draft-ietf-soc-overload-control-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: <http://www.ietf.org/mail-archive/web/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: Tue, 18 Feb 2014 19:39:03 -0000
Spencer and Joe: I am attending to the secdir (Joe) and IESG (Spencer) comments to soc-overload-control-14. It appears that both of you hit on the same piece of text in the draft and requested modifications to it. The text in question is the following paragraph in Section 11 of -14 [1]: Attacks that indicate false overload control can be mitigated by using TCP or Websockets [RFC6455], or better yet, TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be avoided by using TLS on the connection. The gist of your comments revolve around the role of TLS in the above paragraph. Both of you wanted the role highlighted, and in addition Joe thought that the role of BCP 38 should be encouraged in all cases, rather than just with the TLS case. I independently agreed to a modification of the above paragraph with both of you, and now I have to ensure that the independently agreed-to modifications are distilled into a single new paragraph that is acceptable to both of you. Here is the text Joe and I agreed on (Jan 17, 2014): Attacks that indicate false overload control can be mitigated by using TCP or Websockets [RFC6455], or better yet, TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be avoided by using TLS on the connection. Generally, TCP and Websockets in conjunction with BCP-38 make it more difficult for an attacker to insert or modify messages, but it is still possible depending on where the attacker is positioned in the network. TLS provides better protection from an attacker that has access to the network link. And here is the text Spencer and I agreed on (Feb 11, 2014): Attacks that indicate false overload control are best mitigated by by using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be similarly avoided by using TLS on the connection. The use of TCP or Websockets [RFC6455] without TLS can provide some protection, but may be inadequate against an adversary that can modify traffic on links L1 and L2. As you can see, both the suggested texts above appear to be heading in the same direction. I propose the following merger of the suggested texts that I hope will be acceptable to both of you. Attacks that indicate false overload control are best mitigated by using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress genuine overload conditions can be similarly avoided by using TLS on the connection. Generally, TCP and Websockets in conjunction with BCP-38 make it difficult for an attacker to insert or modify messages, but may be inadequate against an adversary that can modify traffic on links L1 and L2. TLS provides the best protection from an attacker with access to the network links. Thank you for your time attending to this email. Please let me know of any changes to the above text. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-14 Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
- [secdir] Collision on changes for draft-ietf-soc-… Vijay K. Gurbani
- Re: [secdir] Collision on changes for draft-ietf-… Vijay K. Gurbani
- Re: [secdir] Collision on changes for draft-ietf-… Spencer Dawkins
- Re: [secdir] Collision on changes for draft-ietf-… Spencer Dawkins