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 ************************************
- Re: [MEXT] MEXT Digest, Vol 22, Issue 23 drafteba… Victor Blake
- Re: [MEXT] MEXT Digest, Vol 22, Issue 23 drafteba… Arnaud Ebalard
- Re: [MEXT] MEXT Digest, Vol 22, Issue 23 drafteba… Victor Blake