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

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Mon, 06 June 2011 17:17 UTC

Return-Path: <ananth@cisco.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 8BAED11E8150; Mon, 6 Jun 2011 10:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.274
X-Spam-Level:
X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 2g1sLJ9dlX9l; Mon, 6 Jun 2011 10:17:02 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DE79811E81B0; Mon, 6 Jun 2011 10:16:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=18506; q=dns/txt; s=iport; t=1307380619; x=1308590219; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=CC3vRE9v2OodcjCyrfJtxdf2eiUsdri8Q8P0yBGrhzg=; b=EEh2kkPMlTUxxymrzusLuUmWdbEfqRVa1ZAwADJ3cVEu/u7CsKdGCVIZ yGU3sQ4jUIVN7AHodMlDl5/W36oh3GRu+BC0KvrsEksYa0BmvvtvaV2tI PUsH7iwQ8ny5SvlRkdMwTP/bxHSyIy8iiWnTR6/7IcELIv0YMCk5n72hG c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwBAHIK7U2rRDoG/2dsb2JhbABTglKUcI5id6tdnWyGIQSGdI5Wiwk
X-IronPort-AV: E=Sophos; i="4.65,327,1304294400"; d="scan'208,217"; a="371165872"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 06 Jun 2011 17:16:46 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p56HGkbZ008440; Mon, 6 Jun 2011 17:16:46 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 10:16:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC246D.830875D4"
Date: Mon, 06 Jun 2011 10:16:45 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC580CE2C5DF@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <4DED059E.5000401@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: sec-dir review of draft-ietf-tcpm-persist-04.txt
Thread-Index: Acwkagc1oNjbkzBbSn2NwzFTgIOqpAAAXvtA
References: <sjm1uz7yo9h.fsf@pgpdev.ihtfp.org> <4DED059E.5000401@cisco.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Mahesh Jethanandani (mahesh)" <mahesh@cisco.com>, Derek Atkins <derek@ihtfp.com>
X-OriginalArrivalTime: 06 Jun 2011 17:16:46.0361 (UTC) FILETIME=[83872890:01CC246D]
Cc: tcpm-chairs@tools.ietf.org, mbashyam@ocarinanetworks.com, iesg@ietf.org, secdir@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: Mon, 06 Jun 2011 17:17:04 -0000

 

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