Subject: Re: [MEXT] Potential new issues for rfc3775bis

From: Julien Laganier <[email-masked]>
Date: Mon, 11 May 2009 13:20:54 +0200

Arnaud,

Sorry that I'm coming back late with this. See below:

On Thursday 26 March 2009, Arnaud Ebalard wrote:
>
> "Charles E. Perkins" <[email-masked]> writes:
> > Hello folks,
> >
> > During and after the last IETF meeting, there were several more
> > topics raised as potential issues to be addressed during the
> > refinement of rfc3775bis.  Here are the ones I have identified
> > from looking through the mail archives:
> >
> > 1. BU de-registration race condition, depending on exactly
> >    when the security information for the mobile node is discarded.
> >
> > 2. Malicious Router Advertisement can cause mobile node
> >    deregistration on foreign network
>
> I was not in SF but expected this issue (2.) to raise some concerns
> and discussions. I was told it was finally dropped at the end of the
> session with the argument that it is considered a NDP issue. Don't
> hesitate to correct me if that summary is incorrect.
>
> AFAICT, NDP was known as an insecure mechanism (just like ARP is)
> when RFC 3775 was written. The Home Link Detection mechanism
> specified in section 11.5.4 of RFC 3775 is based on that insecure
> information.

[...]

> The conclusion could be that this is not a 3775 problem, but a
> 3776/4877 one. Anyway, I think it is a MIPv6 security issue which
> should be considered, clarified and solved in the context of the WG.
>
> Marcelo and Julien, can you provide your chairs' thoughts on previous
> paragraph?

There is no issue at all, and in particular no issue w.r.t. Mobile IPv6. 

It is a given that NDP alone is insecure, and the IETF has a solution: 
Secure Neighbor Discovery (SEND) [RFC3971].

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 11 May 2009 13:40:12 +0200

Hi Julien,

> Sorry that I'm coming back late with this. See below:

No problem. But see below

> Secure Neighbor Discovery (SEND) [RFC3971].

The mail you quote is almost 7 weeks old. Meanwhile (less than 2 weeks
ago), I took the time to make a draft which *precisely* explains the
issues (NDP as a trigger, BU/BA formatting, lose description of expected
processing in RFC 3775, ...) and implementing attacks against a MIPv6
implementation.

I understand you may have a limited amount of time but just nacking the
issues with the 'SEND' magical keyword is a bit easy I think (just my
opinion). If you find the time to just read the draft and still have the
same opinion, then you get my word I won't bother you directly with with
that again. You may even find the draft entertaining ... 

Cheers,

a+

The mail I sent recently:

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