Re: [MEXT] MEXT Digest, Vol 22, Issue 23 draftebalard-mext-hld-security-00.txt

"Victor Blake" <vrparente@aol.com> Thu, 30 April 2009 21:59 UTC

Return-Path: <Vrparente@aol.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782153A6E34 for <mext@core3.amsl.com>; Thu, 30 Apr 2009 14:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 V5uAXKRkBqKS for <mext@core3.amsl.com>; Thu, 30 Apr 2009 14:59:17 -0700 (PDT)
Received: from imo-d22.mx.aol.com (imo-d22.mx.aol.com [205.188.144.208]) by core3.amsl.com (Postfix) with ESMTP id 5FC8A3A6A24 for <mext@ietf.org>; Thu, 30 Apr 2009 14:59:16 -0700 (PDT)
Received: from imo-ma02.mx.aol.com (imo-ma02.mx.aol.com [64.12.78.137]) by imo-d22.mx.aol.com (v107.10) with ESMTP id RELAYIN2-349fa1f6f1e5; Thu, 30 Apr 2009 18:00:15 -0400
Received: from Vrparente@aol.com by imo-ma02.mx.aol.com (mail_out_v40_r1.5.) id l.c87.4d32d441 (34945) for <mext@ietf.org>; Thu, 30 Apr 2009 18:00:04 -0400 (EDT)
Received: from Study ([216.246.69.52]) by cia-da05.mx.aol.com (v123.4) with ESMTP id MAILCIADA056-888149fa1f62241; Thu, 30 Apr 2009 18:00:04 -0400
From: Victor Blake <vrparente@aol.com>
To: mext@ietf.org
References: <mailman.99.1241118011.27309.mext@ietf.org>
In-Reply-To: <mailman.99.1241118011.27309.mext@ietf.org>
Date: Thu, 30 Apr 2009 17:59:38 -0400
Message-ID: <003801c9c9de$f6323ce0$e296b6a0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcnJxoBMXZl12mlFSPWzABQ4vwIhSwAF3OaQ
Content-Language: en-us
X-AOL-IP: 64.12.78.137
Subject: Re: [MEXT] MEXT Digest, Vol 22, Issue 23 draftebalard-mext-hld-security-00.txt
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Apr 2009 21:59:18 -0000

Arnaud,

Your assumption in 4.1 is that the HA relies exclusively on the BU message
from the MN. In fact an HA can rely not only on the BU message itself, but
also the source of the update (BU). That is that the HA, may (not
necessarily but could) know about the Layer 2 source address of MN to
validate the update is coming from the MN it says it is coming from based on
the L3 address. In short, the L2 and L3 address can be correlated.

I believe that there could be other stateful methods as well uses other link
attachment mechanisms such as MIH, DNA, or FMIP in which the sequence in the
state machine would not be valid if such an attack occurred within the
appropriate preceeding and post registration events.

If we try to address the argument beyond just that particular message to
other DoS, I think it is true that there could be cause for concern.
However, regardless of IPsec, Layer 2 DoS attacks would in any event still
be possible. Right ?

-Victor Blake

-----Original Message-----
From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of
mext-request@ietf.org
Sent: Thursday, April 30, 2009 3:00 PM
To: mext@ietf.org
Subject: MEXT Digest, Vol 22, Issue 23

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

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

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send MEXT mailing list submissions to
    mext@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/mext
or, via email, send a message with subject or body 'help' to
    mext-request@ietf.org

You can reach the person managing the list at
    mext-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MEXT digest..."


Today's Topics:

   1.  [draft] MIPv6 Home Link Detection Mechanism Security
      considerations (Arnaud Ebalard)


----------------------------------------------------------------------

Message: 1
Date: Thu, 30 Apr 2009 18:37:45 +0200
From: arno@natisbad.org (Arnaud Ebalard)
Subject: [MEXT] [draft] MIPv6 Home Link Detection Mechanism Security
    considerations
To: IETF MEXT WG ML <mext@ietf.org>
Message-ID: <87eivaksh2.fsf@small.ssi.corp>
Content-Type: text/plain; charset=us-ascii

Hello,

I have just submitted a draft describing possible attacks (implemented
for demonstration against an existing implementation) associated w/ the
Home Link Detection mechanism and the Home Return procedure.

If some among you find some interest in the topic, I'd be interested by
some feedback (questions, comments). 

Link to the document:

http://www.ietf.org/internet-drafts/draft-ebalard-mext-hld-security-00.txt

Cheers,

a+

IETF I-D Submission Tool <idsubmission@ietf.org> writes:

> A new version of I-D, draft-ebalard-mext-hld-security-00.txt has been
> successfuly submitted by Arnaud Ebalard and posted to the IETF
> repository. 
>
> Filename:  draft-ebalard-mext-hld-security
> Revision:  00
> Title:         Mobile IPv6 Home Link Detection Mechanism Security
considerations
> Creation_date:     2009-04-30
> WG ID:         Independent Submission
> Number_of_pages: 32
>
> Abstract:
>
> MIPv6 defines the concept of Home Network for a MN, in opposition to
> the foreign network where this entity may find itself.  A ``Home Link
> Detection'' mechanism is also specified to allow the MN to detect
> when it is at home.
>
> MIPv6 specification mandates the use of IPsec for protecting main
> signaling traffic and also defines how IPsec can be used to protect
> data traffic between the MN and its HA.  Even if optional, it is
> expected that many deployments of MIPv6 will use it by default for MN
> which may roam outside a trusted infrastructure (e.g. outside a
> mobile operator network).
>
> When a MN detects it is at home, it is expected to stop IPsec
> protection for data traffic exchanged with its Home Agent.  That
> event is the result of the Home Return procedure, triggered by the
> Home Link Detection mechanism.
>
> This document discusses the possible threats and security impacts
> associated with the use of this insecure NDP-based mechanism as a
> trigger to drop IPsec protection of data traffic for the MN.  It also
> provides some results on the implementation of the attacks against an
> existing MIPv6 module.  Possible solutions are suggested.




------------------------------

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext


End of MEXT Digest, Vol 22, Issue 23
************************************