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

From: Derek Atkins <[email-masked]>
Date: Mon, 06 Jun 2011 11:26:34 -0400

Hi,

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.

   This document clarifies the Zero Window Probes (ZWP) described in
   Requirements for Internet Hosts [RFC1122].  In particular, it
   clarifies the actions that can be taken on connections which are
   experiencing the ZWP condition.

The security considerations section should refer to section 4 as a
description of the DoS attack, not section 3.  Although it should
still refer to section 3.

Honestly, I find it confusing that the attack is described after some
of the mitigation techniques.  It would make the document flow better,
IMHO, if you describe the attack and then describe how to mitigate the
attack.

The document also mentions orphaned connections but does not mention
how to mitigate an attack against systems that have orphaned
connections.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 6 Jun 2011 10:16:45 -0700

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: [email-masked]; [email-masked]; [email-masked];
[email-masked]; 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: 

-- mj

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 06 Jun 2011 09:51:42 -0700

Derek,

-- mj

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Jun 2011 09:21:32 -0400

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)" <[email-masked]> writes:

> That’s right, the document in its current form blessed by TCPM is a simple
> clarification document of persist condition.
>
> -Anantha
>
> PS:-
>
> * 1. If number of orphaned sockets exceeds an administratively configured
>
> *    limit.
>
>         /* If peer does not open window for long time, or did not transmit
>
>     if ((s32)(tcp_time_stamp - tp->lsndtime) > 2*TCP_RTO_MAX || !do_reset)
>
>                 orphans <<= 1;
>
>                 /* Catch exceptional cases, when connection requires reset.
>
>                 if ((s32)(tcp_time_stamp - tp->lsndtime) <= TCP_TIMEWAIT_LEN |
> |
>
> 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.
>
> condition, the WG felt that it was not necessary to have a section that talked
> about possible solution. The section was therefore removed.
>