[secdir] secdir review of draft-ietf-soc-overload-control-14

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Mon, 13 January 2014 04:45 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E5BA41AE02A; Sun, 12 Jan 2014 20:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MLN5xQWkvP2N; Sun, 12 Jan 2014 20:45:10 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 809D01AE027; Sun, 12 Jan 2014 20:45:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1982; q=dns/txt; s=iport; t=1389588300; x=1390797900; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fFlNTeKGCnAGBYwl78SK+tdSi17i1STXHEylFydwQ9I=; b=jQLRCfA3j61LR1N6Voa308cQTlgVXrBcBPlHYI/Yp4d5nPcjWqTZMk8Y Lib/6G+eXJF5kxgLNsZxflDzTEgbrVarkBhtGoECWcoMBoY9al4eGEE4E p1d/LMSNvBgM4u1aMQWDUROPJn9aengR49OYhaW+QCLVpS1gDXAt+rK3v g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAONu01KtJXG8/2dsb2JhbABagwuBDrpwFnSCLDpRAT5CJwQBiBbEMheSMoETBJgXkhWDLYIq
X-IronPort-AV: E=Sophos;i="4.95,650,1384300800"; d="scan'208";a="12343004"
Received: from rcdn-core2-1.cisco.com ([]) by alln-iport-6.cisco.com with ESMTP; 13 Jan 2014 04:44:59 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com []) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0D4ixiN019101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 04:44:59 GMT
Received: from xmb-rcd-x09.cisco.com ([]) by xhc-aln-x11.cisco.com ([]) with mapi id 14.03.0123.003; Sun, 12 Jan 2014 22:44:59 -0600
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "draft-ietf-soc-overload-control.all@tools.ietf.org" <draft-ietf-soc-overload-control.all@tools.ietf.org>, "<secdir@ietf.org>" <secdir@ietf.org>, "iesg@ietf.org IESG" <iesg@ietf.org>
Thread-Topic: secdir review of draft-ietf-soc-overload-control-14
Thread-Index: AQHPEBo2YX1Dg/QDZk2cs+kAGN4Y7A==
Date: Mon, 13 Jan 2014 04:44:58 +0000
Message-ID: <F174323F-7661-4D97-8B86-E59B1EF3CB4C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <AB0359BB4CF86A4FB9A743645D421B93@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] secdir review of 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: Mon, 13 Jan 2014 04:45:12 -0000

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.

I think this document is ready with some minor issues. 

First I like what you have done with the security considerations section.  It defines the attacks of concern in a clear way and describes some mitigations.  

1.   The security considerations section mentions several mitigations for false overload control messages including TCP, Websockets, BCP-38 and TLS.   While TCP and Websockets provide more protection than UDP its not clear to me that they are providing sufficient protection.   In addition, it seems that BCP-38 should be encouraged in all cases (not just the TLS case).   I'd feel better about the recommendation if it stated some thing like "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."

2.  Some privacy considerations are mentioned in section 5.3.  Its not really clear to me what these considerations are so it would be good to expand upon them in the security considerations section.  

3.  Is it possible that some of the oc-agorithms might have their own security considerations.  If this is likely then it might be good to indicate the reader should check to see if the individual algorithm specifications security considerations. 

4.  Is there any mitigation for the attack involving a proxy that does not support mechanism from blindly forwarding an attacker's oc headers?