[MEXT] [draft] MIPv6 Home Link Detection Mechanism Security considerations

[[e-mail] (Arnaud Ebalard)]

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 <[e-mail]> 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.