Re: [secdir] sec-dir review of draft-ietf-tcpm-persist-04.txt

Derek Atkins <derek@ihtfp.com> Wed, 08 June 2011 13:21 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29F11E80D5; Wed, 8 Jun 2011 06:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.988
X-Spam-Level:
X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubfa30z5BJai; Wed, 8 Jun 2011 06:21:40 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id AA6E911E80D2; Wed, 8 Jun 2011 06:21:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 9635526036E; Wed, 8 Jun 2011 09:21:37 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 22960-04; Wed, 8 Jun 2011 09:21:33 -0400 (EDT)
Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 037B3260326; Wed, 8 Jun 2011 09:21:33 -0400 (EDT)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p58DLWkd017519; Wed, 8 Jun 2011 09:21:32 -0400
From: Derek Atkins <derek@ihtfp.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <sjm1uz7yo9h.fsf@pgpdev.ihtfp.org> <4DED059E.5000401@cisco.com> <0C53DCFB700D144284A584F54711EC580CE2C5DF@xmb-sjc-21c.amer.cisco.com>
Date: Wed, 08 Jun 2011 09:21:32 -0400
In-Reply-To: <0C53DCFB700D144284A584F54711EC580CE2C5DF@xmb-sjc-21c.amer.cisco.com> (Anantha Ramaiah's message of "Mon, 6 Jun 2011 10:16:45 -0700")
Message-ID: <sjm62ogv4pv.fsf@pgpdev.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: tcpm-chairs@tools.ietf.org, "Mahesh Jethanandani (mahesh)" <mahesh@cisco.com>, secdir@ietf.org, mbashyam@ocarinanetworks.com, iesg@ietf.org
Subject: Re: [secdir] sec-dir review of draft-ietf-tcpm-persist-04.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 08 Jun 2011 13:21:41 -0000

Hi,

If this is the working group concensus then I would ask that you please
add a paragraph or two to the Security Considerations section and
explain that in more detail, please?  Maybe base it on Mahesh's text
below?

Thanks!

-derek

"Anantha Ramaiah (ananth)" <ananth@cisco.com> writes:

> That’s right, the document in its current form blessed by TCPM is a simple
> clarification document of persist condition.
>
> -Anantha
>
> PS:-
>
> FWIW, Linux handles such a scenario.  (orphaned connections)
>
> Code snippet of the relevant function below :- (tcp_timer.c)
>
> /* Do not allow orphaned sockets to eat all our resources.
>
> * This is direct violation of TCP specs, but it is required
>
> * to prevent DoS attacks. It is called when a retransmission timeout
>
> * or zero probe timeout occurs on orphaned socket.
>
> *
>
> * Criteria is still not confirmed experimentally and may change.
>
> * We kill the socket, if:
>
> * 1. If number of orphaned sockets exceeds an administratively configured
>
> *    limit.
>
> * 2. If we have strong memory pressure.
>
> */
>
> static int tcp_out_of_resources(struct sock *sk, int do_reset)
>
> {
>
>         struct tcp_sock *tp = tcp_sk(sk);
>
>         int orphans = atomic_read(&tcp_orphan_count);
>
>         /* If peer does not open window for long time, or did not transmit
>
>          * anything for long time, penalize it. */
>
>     if ((s32)(tcp_time_stamp - tp->lsndtime) > 2*TCP_RTO_MAX || !do_reset)
>
>                 orphans <<= 1;
>
>         /* If some dubious ICMP arrived, penalize even more. */
>
>         if (sk->sk_err_soft)
>
>                 orphans <<= 1;
>
>         if (tcp_too_many_orphans(sk, orphans)) {
>
>                 if (net_ratelimit())
>
>                         printk(KERN_INFO "Out of socket memory\n");
>
>                 /* Catch exceptional cases, when connection requires reset.
>
>                  *      1. Last segment was sent recently. */
>
>                 if ((s32)(tcp_time_stamp - tp->lsndtime) <= TCP_TIMEWAIT_LEN |
> |
>
>                     /*  2. Window is closed. */
>
>                     (!tp->snd_wnd && !tp->packets_out))
>
>                         do_reset = 1;
>
>                 if (do_reset)
>
>                           tcp_send_active_reset(sk, GFP_ATOMIC);
>
>             tcp_done(sk);
>
>                 NET_INC_STATS_BH(LINUX_MIB_TCPABORTONMEMORY);
>
>                 return 1;
>
>         }
>
>         return 0;
>
> }
>
> From: Mahesh Jethanandani (mahesh)
> Sent: Monday, June 06, 2011 9:52 AM
> To: Derek Atkins
> Cc: iesg@ietf.org; secdir@ietf.org; tcpm-chairs@tools.ietf.org;
> mbashyam@ocarinanetworks.com; Anantha Ramaiah (ananth)
> Subject: Re: sec-dir review of draft-ietf-tcpm-persist-04.txt
>
> Derek,
>
> After lot of discussion regarding the scope of this document, the WG felt that
> the draft should be limited to clarifying the language in RFC 1122. If you
> were to look at earlier versions of the draft, we had a section in the draft
> that talked about possible mitigation techniques and socket level API changes
> that would be needed to be able to determine which connections were stuck in
> persist condition.
>
> Once the scope was defined as clarifying senders behavior in persist
> condition, the WG felt that it was not necessary to have a section that talked
> about possible solution. The section was therefore removed.
>
> On 6/6/2011 8:26 AM, Derek Atkins wrote:
>
> The document also mentions orphaned connections but does not mention
> how to mitigate an attack against systems that have orphaned
> connections.
>
> -- mj
>

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant