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

"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 17 January 2014 21:40 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 371A11AE181; Fri, 17 Jan 2014 13:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 wp64D-hL6a2J; Fri, 17 Jan 2014 13:40:52 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 495451AD6C1; Fri, 17 Jan 2014 13:40:50 -0800 (PST)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s0HLeUTv015389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Jan 2014 15:40:30 -0600 (CST)
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s0HLeTxe031797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 15:40:30 -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 s0HLeTgt022231; Fri, 17 Jan 2014 15:40:29 -0600 (CST)
Message-ID: <52D9A37B.5020301@bell-labs.com>
Date: Fri, 17 Jan 2014 15:41:15 -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.2.0
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, "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>
References: <F174323F-7661-4D97-8B86-E59B1EF3CB4C@cisco.com>
In-Reply-To: <F174323F-7661-4D97-8B86-E59B1EF3CB4C@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.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Subject: Re: [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: Fri, 17 Jan 2014 21:40:55 -0000

On 01/12/2014 10:44 PM, Joseph Salowey (jsalowey) wrote:
> 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.

Joe: Thank you for your time and attention to the details of the
document in general, and the security considerations in particular.

Please see inline for possible resolutions and follow ups.

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

Excellent; thank you!

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

I think that is reasonable.  I can pretty much include the text you
provide above verbatim in Section 11 (Security Considerations) as
follows:

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

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

Let me know if that addresses your concern.

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

I think you meant Section 5.2, above (the word "privacy" appears in
Section 5.2).  Essentially, what is meant by the loss of privacy
here is the knowledge that a random upstream client gains --- without
much effort on its part ---  that the supports overload.  If, on the
other hand, the server had a policy of only indicating overload
support for those requests it received over a trusted channel where
the identity of the client could be asserted, then its may loosen
its inhibitions and indicate overload control.  It is the inadvertent
leakage of a capability (supports overload) to untrusted clients that
is of concern here.

I could insert a couple of sentences as the last paragraph of Section
11; candidate text below:

    Indicating support for overload control in a request received on
    an untrusted link can leak privacy in the form of capability support
    of the server.  To limit the knowledge that the server supports
    overload control, a server can adopt a policy of inserting overload
    control support in only those requests received over trusted links.

Reasonable?

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

Do we need to add anything specific here?  If other overload control
algorithms beyond rate and loss are standardized, I suspect that they
will contain an appropriate Security Consideration section of their
own.  I am happy to add some text exhorting the implementor to
consult the specific overload control algorithm document if you feel
strongly about it.  Please let me know.

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

Alas, no.  As per the SIP processing rules, a proxy that does not
understand any Via header parameters is asked to simply tokenize
them on the way in and serialize them on the way out.  Thus, a
proxy that does not support this specification will simply forward
the overload control markings downstream.

Again, thanks for a close read.  Please let me know if the resolutions
specified in this email form a reasonable basis to move ahead.

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