[humanresolv] Invitation to humanresolvers ML (was: Re: [MEXT] Energy consumption attacks)

Pars Mutaf <pars.mutaf@gmail.com> Wed, 23 March 2011 10:53 UTC

Return-Path: <pars.mutaf@gmail.com>
X-Original-To: humanresolvers@core3.amsl.com
Delivered-To: humanresolvers@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CE33A6800; Wed, 23 Mar 2011 03:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level:
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO1fJtPMEjep; Wed, 23 Mar 2011 03:53:34 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id DEAE83A6801; Wed, 23 Mar 2011 03:53:33 -0700 (PDT)
Received: by qwg5 with SMTP id 5so6764269qwg.31 for <multiple recipients>; Wed, 23 Mar 2011 03:55:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=0JdEikf2Ayh93Om4n9xd0xObb+kB+IwVxP3Owr6+1S0=; b=aD+jpX6XMyTW3YAL9nXYKtYK+yLnpZv7KGgZgtphfxvwQW1Vdsv42b704LsGPgqaj1 J+Zq1nXhjgfyvUxzCvUIOyXXDImb7NOUgTdpMC2dyraqaWBFefBc7dsPbvdxf6t0+93o Z0kveKmpSDip2sEYBuLWi817VzT6zLWYFrFSg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uB+P0+GoFTgql5dBkj8tRxNlOWoIbPpJxtNEnneBZqGQ/FTELq60rDQrRu1/O9QCeP QPqQ5YpJJlrost21Ywi70QMTuwIbkIXr3/1xBWaZoVkgidkLWuFcHT9qVQ5QUgXRIYk3 aFUbCrtQlYYhITjEv7XYXI1/GavxD8AEBgnzM=
MIME-Version: 1.0
Received: by 10.224.137.32 with SMTP id u32mr5870822qat.322.1300877707181; Wed, 23 Mar 2011 03:55:07 -0700 (PDT)
Received: by 10.224.67.13 with HTTP; Wed, 23 Mar 2011 03:55:07 -0700 (PDT)
Date: Wed, 23 Mar 2011 12:55:07 +0200
Message-ID: <AANLkTimDb5TH+yYPbLqhaO2iOiwu-R4VPsaJop8wz72_@mail.gmail.com>
From: Pars Mutaf <pars.mutaf@gmail.com>
To: Julien Laganier <julien.ietf@gmail.com>, mext@ietf.org, humanresolvers@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.9
Subject: [humanresolv] Invitation to humanresolvers ML (was: Re: [MEXT] Energy consumption attacks)
X-BeenThere: humanresolvers@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <humanresolvers.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/humanresolvers>
List-Post: <mailto:humanresolvers@ietf.org>
List-Help: <mailto:humanresolvers-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Mar 2011 10:53:35 -0000

Hi Julien, all,

We have a mailing list (humanresolvers) that was initially created to work
on the
higher level spam attacks on low-end mobile IP devices that consume host
resources
e.g. energy, CPU and memory, and annoy the user. We can expand the problem
scope
to primarily work on the IP-layer energy consuming Denial-of-Service (DoS)
attacks that
consist of sending large number of IP spoofing malicious packets to a victim
without
opening valid sessions (see description below). New attacks may also be
discovered.

The mailing list address is as follows:

https://www.ietf.org/mailman/listinfo/humanresolvers

Problem statement:
==============

Battery powered mobile IP hosts will probably be victim of new
Denial-of-Service (DoS)
attacks that consume limited host resources e.g. energy, CPU and memory. An
attacker
can remotely consume victim mobile hosts' battery by continuously sending
them bogus
session initiating packets e.g. SIP INTIVE or TCP SYN. A simple defense e.g.
attempting
to drop malicious packets would result in mobile host unreachability, since
the victim
cannot possibly differentiate between legitimate and malicious session
initiating packets
purportedly coming from random IP addresses.

When under attack, a victim will consume energy for:

- Receiving the messages (continuously waking up from sleep mode)
- Processing them and preparing reply packets (L2 and L3)
- Sending replies (L2 ACKs and upper layer replies e.g. SIP or TCP replies)

Serious design efforts are being made in MAC layer access technologies to
enable energy
conserving sleep mode. The attack would not only foil these efforts, but
also consume energy
by "forcing" the victim to send replies to frequent malicious packets
purportedly coming from
random IP addresses. For example, simple experiments show that the battery
of a mobile
phone with 802.11 access can be remotely consumed in ~3 hours (full battery,
1350 mAh).
The attack may shut down the victim device more quickly if its battery level
is low. Attacks
on phones using an outdoor technology would result in faster energy
consumption due to the
longer distances to the base station.

At a higher level, attackers can also organize spamming attacks that consume
victims'
resources and annoy the users by sending spam.

I would like to invite interested folks to subscribe to discuss these
problems.

Regards,

Pars


On Tue, Mar 22, 2011 at 5:39 PM, Julien Laganier <julien.ietf@gmail.com>wrote:

> Hello Pars,
>
> I can agree that the topic can be of interest to the MIPv6 community
> and thus it would be appropriate to post on the list a pointer to a
> place where the topic is being discussed. However since the attacks
> are generic and not specific to the MIPv6 protocol suite, I believe
> discussions on the topic itself are out-of-scope for this mailing
> list.
>
> Thanks,
>
> --julien
>
> On Tue, Mar 22, 2011 at 1:59 AM, Pars Mutaf <pars.mutaf@gmail.com>; wrote:
> > Hi Julien,
> >
> > MIPv6 is mostly about battery powered mobile hosts, so I think this topic
> > should be of interest to Mobile IPv6 community. Secondly, when you think
> > about solutions, you may realize that it is an IP layer problem. Any
> upper
> > layer host identifier (FQDN or SIP URI etc) would be resolved to the
> "fixed"
> > home address of the mobile host and once the attacker has learned it, the
> > attack is possible. The attacker can remotely consume the victim's
> energy.
> > Application layer solutions like spam filtering would be useless because
> the
> > attacker is simply sending bogus packets, not even opening sessions.
> >
> > In fact, we may expand the problem space since there may be other
> problems
> > due to having a fixed MIPv6 home address. But I think the remote energy
> > consumption attack is the most serious one. Serious design efforts are
> being
> > made at MAC layer to enable energy conserving sleep mode. The attack
> would
> > not only foil these efforts, but also consume energy by "forcing" the
> victim
> > to reply to frequent malicious packets purportedly coming from random IP
> > addresses.
> >
> > Thanks,
> >
> > Pars
> >
> > On Tue, Mar 22, 2011 at 5:27 AM, Julien Laganier <julien.ietf@gmail.com>;
> > wrote:
> >>
> >> Pars -
> >>
> >> How is this attack related to MIPv6?
> >>
> >> --julien
> >>
> >> On Mon, Mar 21, 2011 at 2:43 AM, Pars Mutaf <pars.mutaf@gmail.com>;
> wrote:
> >> > Hello,
> >> >
> >> > I was wondering if solutions to energy consumption attacks on battery
> >> > powered mobile hosts would be of interest to IETF Mobile IPv6
> community.
> >> >
> >> > The attack consists of sending frequent request packets e.g. SIP
> INVITE
> >> > or
> >> > TCP SYN to a victim's home address.
> >> >
> >> > For example, experiments showed that the battery of a mobile phone
> with
> >> > 802.11 access can be remotely consumed in 3 hours (full battery).
> >> > Attacks on
> >> > phones using an outdoor technology would result in more energy
> >> > consumption
> >> > because of the longer distance to the base station.
> >> >
> >> > The victim becomes unusable.
> >> >
> >> > Regards,
> >> >
> >> > Pars
> >> >
> >> > _______________________________________________
> >> > MEXT mailing list
> >> > MEXT@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/mext
> >> >
> >> >
> >
> >
>