Re: [MEXT] re-direction attack on MCoA

[RYUJI WAKIKAWA <[e-mail]>]

Hi All,

Thanks for all your comments. I agree with George and see the progress.

I treated this action as a consensus.
We will not include the Ben's solution in the MCoA and leave it to  
other work.

thanks,
ryuji



On 2008/01/31, at 20:08, George Tsirtsis wrote:

> I am of course also interested in this work. I guess we already have
> enough people to get the ball rolling on this.
>
> Thanks
> George
>
> On Jan 31, 2008 10:59 AM, Suresh Krishnan <[e-mail] 
> > wrote:
>> Hi Marcelo,
>>  I am willing to work on a generic MIPv6 threats document along  
>> with the other interested people.
>>
>> Cheers
>> Suresh
>>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[e-mail]]
>> Sent: January 31, 2008 11:13 AM
>> To: Wassim Haddad
>> Cc: Julien Laganier; [e-mail]
>>
>> Subject: Re: [MEXT] re-direction attack on MCoA
>>
>>
>> El 30/01/2008, a las 19:16, Wassim Haddad escribió:
>>>
>>> => As there is a clear interest in the redirection attack on the HA
>>> side, I volunteer to do some work on this one.
>>>
>>
>> I think the work should be general to all residual threats on MIP as
>> George mentioned, i think this would be more interesting since it
>> would allow us to put the different threats in perspective and figure
>> out which ones we should address.
>>
>>
>>
>>>
>>> Regards,
>>>
>>> Wassim H.
>>>
>>>
>>>> El 30/01/2008, a las 18:19, Wassim Haddad escribió:
>>>>
>>>>> Hi Marcelo,
>>>>> IMHO, this topic has to be included as a new item in the new
>>>>> charter and
>>>>> should not be limited to MCoA.
>>>>> Regards,
>>>>> Wassim H.
>>>>> On Wed, 30 Jan 2008, marcelo bagnulo braun wrote:
>>>>>> Pascal,
>>>>>> The question at this point is the following one: do you think
>>>>>> that this threat should be addressed in the MCoA draft itself?
>>>>>> comments?
>>>>>> Regards, marcelo
>>>>>> El 30/01/2008, a las 10:09, Pascal Thubert (pthubert) escribió:
>>>>>>> I agree with Wassim on both mails.
>>>>>>> There's also the situation where the MN/MR might be fooled by  
>>>>>>> the
>>>>>>> visited network into believing that the CoA (or its prefix if a
>>>>>>> network
>>>>>>> is attacked as opposed to a host) is on the visited link. DSMIP
>>>>>>> is also
>>>>>>> exposed, in particular with IPv4 CoAs.
>>>>>>> There are many scenarios that do not involve high mobility were
>>>>>>> a 3-way
>>>>>>> or a 4-way handshake could be used to verify the CoA. We have
>>>>>>> proposed
>>>>>>> such a test in section 6 of the RRH draft that uses a triggered
>>>>>>> 2nd BU
>>>>>>> flow to verify the CoA in the first one:
>>>>>>> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header-07#
>>>>>>> section-6
>>>>>>> Pascal
>>>>>>>> -----Original Message-----
>>>>>>>> From: Wassim Haddad [mailto:[e-mail]]
>>>>>>>> Sent: mercredi 30 janvier 2008 09:32
>>>>>>>> To: Benjamin Lim
>>>>>>>> Cc: 'Julien Laganier'; [e-mail]
>>>>>>>> Subject: RE: [MEXT] re-direction attack on MCoA
>>>>>>>> On Wed, 30 Jan 2008, Benjamin Lim wrote:
>>>>>>>>> All in all, what I am trying to say is that tracing only
>>>>>>>>> limits the
>>>>>>>>> effect of the attack from escalating further and not
>>>>>>>>> preventing it.
>>>>>>>> => which (again) also perfectly applies to a single CoA.
>>>>>>>> Regards,
>>>>>>>> Wassim H.
>>>>>>>> _______________________________________________
>>>>>>>> MEXT mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>>>>> _______________________________________________
>>>>>>> MEXT mailing list
>>>>>>> [e-mail]
>>>>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> [e-mail]
>>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/mext
>>
>>
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mext
>>
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mext
>>
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/mext
From [e-mail]  Fri Feb  1 02:34:19 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E0E5F3A6913;
	Fri,  1 Feb 2008 02:34:19 -0800 (PST)
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=[AWL=0.000,
	BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id K1pTobeUTc0C; Fri,  1 Feb 2008 02:34:18 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 589253A689E;
	Fri,  1 Feb 2008 02:34:18 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 447343A6880
	for <[e-mail]>; Fri,  1 Feb 2008 02:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id VUsh-4+IThjw for <[e-mail]>;
	Fri,  1 Feb 2008 02:34:15 -0800 (PST)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176])
	by core3.amsl.com (Postfix) with ESMTP id 83DFF3A689E
	for <[e-mail]>; Fri,  1 Feb 2008 02:34:15 -0800 (PST)
Received: by py-out-1112.google.com with SMTP id x19so1135977pyg.24
	for <[e-mail]>; Fri, 01 Feb 2008 02:35:49 -0800 (PST)
Received: by 10.110.2.2 with SMTP id 2mr1807454tib.14.1201862147473;
	Fri, 01 Feb 2008 02:35:47 -0800 (PST)
Received: from ?203.178.143.210? ( [203.178.143.210])
	by mx.google.com with ESMTPS id h38sm115638wxd.15.2008.02.01.02.35.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 01 Feb 2008 02:35:42 -0800 (PST)
From: RYUJI WAKIKAWA <[e-mail]>
To: George Tsirtsis <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v915)
Date: Fri, 1 Feb 2008 19:35:35 +0900
X-Mailer: Apple Mail (2.915)
Cc: [e-mail]
Subject: Re: [MEXT] re-direction attack on MCoA
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/mext>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/mext>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

George,

Thanks for summary.
I agree this issue is not specific to MCoA.

>  In fact I think the following should
> be removed form the MCoA draft.....possibly moved to the flow
> filtering draft.:
> "   This valid care-of address could then be used by the malicious  
> mobile
>   node to set up flow filtering rules at its home agent, thereby
>   controlling and/or launching new re-direction attacks."

OK

regards,
ryuji


On 2008/01/29, at 19:58, George Tsirtsis wrote:

> Hi Ben, et.al.,
>
> While the issue you point out is real (everyone seems to agree with
> that) it falls under the category of traceable attacks, as others have
> already pointed out. In MIPv6 we never really considered the issue of
> a "fake" CoAs as a very important one (Only MIPv4 FA Mode deals with
> that). Indeed, several attacks, like the redirection attack you point
> out are possible, even without MCoA support. But other attacks are
> also possible without MCoA support e.g., an MN associates with two
> different HAs and registers the HoA from the first as the CoA for the
> second and vice versa, creating a routing loop.
>
> So, I share the sentiment of the group that mitigation techniques
> should be defined outside the MCoA spec, and I would suggest we
> actually expand the scope of these techniques to cover also other
> cases involving CoA based attacks.
>
> In any case the attack you describe for the MCoA case does not become
> really interesting unless it is combined with flow filtering which is
> out of scope of the MCoA draft. In fact I think the following should
> be removed form the MCoA draft.....possibly moved to the flow
> filtering draft.:
> "   This valid care-of address could then be used by the malicious  
> mobile
>   node to set up flow filtering rules at its home agent, thereby
>   controlling and/or launching new re-direction attacks."
>
> Regards
> George
>
> On Jan 29, 2008 3:03 AM, Benjamin Lim  
> <[e-mail]> wrote:
>> Hi Vijay,
>>
>> =8=8<=8=
>>> FWIW, for the current draft, I think it is sufficient to
>>> point out the threats in the security considerations section.
>>> The home agent knows which mobile node launched the attch, so
>>> that should be a deterrent. We should not require the CoA to
>>> be a CGA, require CBA or mandate a return routability test
>>> for the CoA for the multiple CoA extension.
>> [Ben] I am not mandating a solution for CoA testing yet. My  
>> intention in my
>> draft was to analyze and discuss the best way to solve the problem.  
>> Till
>> then, I feel it might be better to list the current possible  
>> approaches to
>> the problem in the MCoA draft. These approaches serves as some  
>> options that
>> implementers can take to help advert such problem.
>>
>>>
>>> I also think we should add an informative reference pointing
>>> to draft-lim-mext-multiple-coa-verify-00 for preventing the attack.
>> [Ben] A standard track document pointing to a draft that may expire  
>> for
>> solutions. I am not sure if this is the correct way to go.
>>
>> Regards,
>> Benjamin Lim
>>
>>
>>>
>>> Vijay
>>>
>>> Benjamin Lim wrote:
>>>> Hi,
>>>>
>>>> Some points inline to start of discussion.
>>>>
>>>>> -----Original Message-----
>>>>> From: RYUJI WAKIKAWA [mailto:[e-mail]]
>>>>> Sent: Monday, January 28, 2008 11:27 AM
>>>>> To: [e-mail]
>>>>> Subject: [MEXT] re-direction attack on MCoA
>>>>>
>>>>> Hi,
>>>>>
>>>>> At the last IETF meeting, Benjamin presented the security
>>>>> vulnerability of MCoA, re-direction attack.
>>>>> Benjamin's text is merged into the security consideration
>>> section.
>>>>> Thanks Benjamin.
>>>>>
>>>>> However, we didn't merge the solution part in the MCoA.
>>>>> The proposed solution is more like an extension and should
>>> be written
>>>>> in the separate document.
>>>>> We believe the issue of re-direction attack should not be often
>>>>> happened because a malicious mobile node is always traceable by an
>>>>> operator (i.e. HA).
>>>>> A mobile node must take certain risk to do re-direction attack.
>>>> [Ben] Such risk taken by the mobile node does factor into
>>> the account
>>>> on wether the attack will occur. However, I find it hard to justify
>>>> that such risk will prevent such attack from happening
>>> often. If more
>>>> and more attackers are willingly to take such risk (e.g.
>>> strong sense
>>>> of purpose or even 'big ego') or there exisit better mechnisam that
>>>> helps mask the attacker identity in the future, can we say
>>> that such
>>>> attacks will not happen often?
>>>>
>>>>> For the MCoA document it should be sufficient to just
>>> point out this
>>>>> threats.
>>>> [Ben] This is my point of view. As this is a standard
>>> tracks document
>>>> for a protocol, stating a possible miuse of the protocol (aka loop
>>>> hole) without providing some soultions or guideline to it
>>> seems funny.
>>>> Its like saying "hey you can exploit this protocol this way. How to
>>>> slove/prevent it, crack your own brains" Hence, my intention of the
>>>> below proposed text is to serve as a guide that such exploit can be
>>>> reduce/prevent with some methods. This I feel helps
>>> implementers as we
>>>> provide some basic steps to help advert such misuse.
>>>>
>>>> Would appericate any comments to help in this discussion. Thanks!
>>>>
>>>> Regards,
>>>> Benjamin Lim
>>>>> If you have any comments, let us know.
>>>>> I attach the Benjamin's proposed text.
>>>>>
>>>>> thanks
>>>>> ryuji
>>>>>
>>>>>
>>>>>
>>>>> To mitigate such risk described in Section 9, one approach
>>> is for the
>>>>> care-of address to be secured cryptographically (CGA) [RFC-3972],
>>>>> thus permitting the home agent to know if the mobile node actually
>>>>> owns that particular care-of address listed in the binding update
>>>>> message.
>>>>> However,
>>>>> introducing cryptographically generated care-of addresses might
>>>>> increase the complexity of the mechanism to achieve
>>> multiple bindings
>>>>> such as how a message can contain multiple CGA signatures
>>> for each of
>>>>> the care-of addresses, integration between the CGA module and
>>>>> Mobility Support module in a network stack implementation
>>> and further
>>>>> increasing the size of the binding update message.
>>> Furthermore, using
>>>>> CGA does not prevent a malicious mobile node to launch a flooding
>>>>> attack against a subnet by generating multiple
>>> non-existent care-of
>>>>> addresses in that subnet using the mobile node's own public keys.
>>>>>
>>>>> Another approach to mitigate the risk is to employ some means at a
>>>>> home agent to limit the amount of information that a home
>>> agent can
>>>>> send to a care-of address that has not be tested for its
>>>>> reachability. This reduces the chances of the home agent from
>>>>> flooding packets to a particular untested care-of address.
>>> A possible
>>>>> technique to achieve this is to use credit- based
>>> authorization (CBA)
>>>>> [RFC-4866]. In this technique, for the home agent to fully use the
>>>>> care-of address for packet routing, the home agent would need to
>>>>> receive a packet from the mobile node from the untested care-of
>>>>> address.
>>>>> However, the packets that the home agent receives from
>>> these untested
>>>>> care-of addresses might not be sent by the mobile node.
>>> Hence, this
>>>>> technique and the following few proposed techniques will
>>> henceforth
>>>>> assumes that ingress filtering within the network is done. For
>>>>> example, a mobile node can use the Internet Control
>>> Message Protocol
>>>>> (ICMP) described in [RFC-792] to send a request message
>>> via its home
>>>>> address to a untested victim care-of address, thereby triggering a
>>>>> response from this care-of address. Also, in situations where an
>>>>> interface of the mobile node has asymmetrical link characteristics
>>>>> (e.g. General Packet Radio System), that particular
>>> interface might
>>>>> have resource constraint on its upload path making it costly for a
>>>>> mobile node to send a packet to its home agent using that
>>> particular
>>>>> interface.
>>>>>
>>>>> In yet another approach, instead of the home agent waiting for a
>>>>> packet to fully utilize a care-of address for routing, it might be
>>>>> possible for the home agent to send a packet to a untested care-of
>>>>> address to trigger a response from the mobile node from
>>> that care-of
>>>>> address. One technique described in [ID-RRCOOKIE] uses a cookie to
>>>>> prove to the home agent that the mobile node is reachable at a
>>>>> specified care-of address. Another technique could employ
>>> the use of
>>>>> the Binding Refresh Request message to trigger the mobile node to
>>>>> send a binding update message from that care-of address to
>>> the mobile
>>>>> node. However, this technique of testing reduces the optimization
>>>>> benefit of sending bulk registration as it would require
>>> the mobile
>>>>> node to respond via all these care-of addresses. In this case, the
>>>>> mobile node might as well send the binding update message
>>>>> individually for each care-of address.
>>>>>
>>>>> To optimize the previous approach in order to keep the benefits of
>>>>> bulk registration, the home agent could test the care-of
>>> address by
>>>>> asking a mobile node to reply from a different care-of address as
>>>>> oppose to the care-of address that was used by the home
>>> agent to send
>>>>> the trigger message.
>>>>> This utilizes the concept of multiple care-of addresses
>>> whereby the
>>>>> mobile node need not respond back using the same path as the
>>>>> reception of the request. Such a concept is particularly useful in
>>>>> the event that the mobile node has several unverified care-of
>>>>> addresses that needs to be tested.
>>>>> By
>>>>> asking the mobile node to respond via another care-of
>>> address, in one
>>>>> round trip time, the home agent would be able to verify
>>> two care-of
>>>>> addresses.
>>>>>
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> [e-mail]
>>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mext
>>
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/mext
From [e-mail]  Fri Feb  1 05:43:11 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id AEABC28E4F5
	for <[e-mail]>; Fri,  1 Feb 2008 05:42:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010,
	BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id c+SUBz-B7WeW for <[e-mail]>;
	Fri,  1 Feb 2008 05:42:37 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 57514293119
	for <[e-mail]>; Fri,  1 Feb 2008 05:17:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: [e-mail]
To: [e-mail]
X-No-Archive: yes
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2008 05:03:48 -0800
Precedence: bulk
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
List-Id: <mailman.core3.amsl.com>
X-List-Administrivia: yes
Sender: [e-mail]
Errors-To: [e-mail]

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, [e-mail]) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

If you have questions, problems, comments, etc, send them to
[e-mail].  Thanks!

http://www.ietf.org/mailman/options/mext/mext-archive%40optimus.ietf.org
From [e-mail]  Fri Feb  1 05:46:07 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B26B928C7D9
	for <[e-mail]>; Fri,  1 Feb 2008 05:42:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010,
	BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ezMeoOqaKIAU for <[e-mail]>;
	Fri,  1 Feb 2008 05:42:53 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 758DF2931BF
	for <[e-mail]>; Fri,  1 Feb 2008 05:17:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: [e-mail]
To: [e-mail]
X-No-Archive: yes
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2008 05:03:50 -0800
Precedence: bulk
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
List-Id: <mailman.core3.amsl.com>
X-List-Administrivia: yes
Sender: [e-mail]
Errors-To: [e-mail]

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, [e-mail]) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

If you have questions, problems, comments, etc, send them to
[e-mail].  Thanks!

http://www.ietf.org/mailman/options/mext/mext-archive%40optimus.ietf.org
From [e-mail]  Fri Feb  1 09:32:00 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8559028C3BE;
	Fri,  1 Feb 2008 09:32:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.762
X-Spam-Level: 
X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id mos-owb0lD7f; Fri,  1 Feb 2008 09:32:00 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 41A8428C387;
	Fri,  1 Feb 2008 09:31:51 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C9F8A28C387
	for <[e-mail]>; Fri,  1 Feb 2008 09:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id v481-uoPjXcY for <[e-mail]>;
	Fri,  1 Feb 2008 09:31:49 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133])
	by core3.amsl.com (Postfix) with ESMTP id E7ACD3A68A6
	for <[e-mail]>; Fri,  1 Feb 2008 09:31:44 -0800 (PST)
Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es 
	[163.117.139.76])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No
	client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 
	172372C68F9;Fri,  1 Feb 2008 18:33:18 +0100 (CET)
Message-Id: <[e-mail]>
From: marcelo bagnulo braun <[e-mail]>
To: RYUJI WAKIKAWA <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v915)
Date: Fri, 1 Feb 2008 18:33:16 +0100
References: <[e-mail]
	.com><[e-mail]><Pine.LNX.4.64.08013
	0 
	[e-mail]><[e-mail]3m
	.es><[e-mail]><E4A82F11-1FA6-4908
	- 
	[e-mail]><6D19CA8D71C89C43A057926FE0D4ADAA232B6D@ecamlm
	w720.eamcs.ericsson.se><d3886a520801310308u937f976u214dff17a050d97b@mail.g
	mail.com> <[e-mail]>
X-Mailer: Apple Mail (2.915)
X-imss-version: 2.049
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-30.4878 TC:1F TRN:51 TV:5.0.1023(15704.000)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Cc: Julien Laganier <[e-mail]>, [e-mail]
Subject: Re: [MEXT] re-direction attack on MCoA
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/mext>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/mext>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Errors-To: [e-mail]

right

El 01/02/2008, a las 11:33, RYUJI WAKIKAWA escribió:

> Hi All,
>
> Thanks for all your comments. I agree with George and see the  
> progress.
>
> I treated this action as a consensus.
> We will not include the Ben's solution in the MCoA and leave it to
> other work.
>
> thanks,
> ryuji
>
>
>
> On 2008/01/31, at 20:08, George Tsirtsis wrote:
>
>> I am of course also interested in this work. I guess we already have
>> enough people to get the ball rolling on this.
>>
>> Thanks
>> George
>>
>> On Jan 31, 2008 10:59 AM, Suresh Krishnan <[e-mail]
>>> wrote:
>>> Hi Marcelo,
>>> I am willing to work on a generic MIPv6 threats document along
>>> with the other interested people.
>>>
>>> Cheers
>>> Suresh
>>>
>>> -----Original Message-----
>>> From: marcelo bagnulo braun [mailto:[e-mail]]
>>> Sent: January 31, 2008 11:13 AM
>>> To: Wassim Haddad
>>> Cc: Julien Laganier; [e-mail]
>>>
>>> Subject: Re: [MEXT] re-direction attack on MCoA
>>>
>>>
>>> El 30/01/2008, a las 19:16, Wassim Haddad escribió:
>>>>
>>>> => As there is a clear interest in the redirection attack on the HA
>>>> side, I volunteer to do some work on this one.
>>>>
>>>
>>> I think the work should be general to all residual threats on MIP as
>>> George mentioned, i think this would be more interesting since it
>>> would allow us to put the different threats in perspective and  
>>> figure
>>> out which ones we should address.
>>>
>>>
>>>
>>>>
>>>> Regards,
>>>>
>>>> Wassim H.
>>>>
>>>>
>>>>> El 30/01/2008, a las 18:19, Wassim Haddad escribió:
>>>>>
>>>>>> Hi Marcelo,
>>>>>> IMHO, this topic has to be included as a new item in the new
>>>>>> charter and
>>>>>> should not be limited to MCoA.
>>>>>> Regards,
>>>>>> Wassim H.
>>>>>> On Wed, 30 Jan 2008, marcelo bagnulo braun wrote:
>>>>>>> Pascal,
>>>>>>> The question at this point is the following one: do you think
>>>>>>> that this threat should be addressed in the MCoA draft itself?
>>>>>>> comments?
>>>>>>> Regards, marcelo
>>>>>>> El 30/01/2008, a las 10:09, Pascal Thubert (pthubert) escribió:
>>>>>>>> I agree with Wassim on both mails.
>>>>>>>> There's also the situation where the MN/MR might be fooled by
>>>>>>>> the
>>>>>>>> visited network into believing that the CoA (or its prefix if a
>>>>>>>> network
>>>>>>>> is attacked as opposed to a host) is on the visited link. DSMIP
>>>>>>>> is also
>>>>>>>> exposed, in particular with IPv4 CoAs.
>>>>>>>> There are many scenarios that do not involve high mobility were
>>>>>>>> a 3-way
>>>>>>>> or a 4-way handshake could be used to verify the CoA. We have
>>>>>>>> proposed
>>>>>>>> such a test in section 6 of the RRH draft that uses a triggered
>>>>>>>> 2nd BU
>>>>>>>> flow to verify the CoA in the first one:
>>>>>>>> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header-07#
>>>>>>>> section-6
>>>>>>>> Pascal
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Wassim Haddad [mailto:[e-mail]]
>>>>>>>>> Sent: mercredi 30 janvier 2008 09:32
>>>>>>>>> To: Benjamin Lim
>>>>>>>>> Cc: 'Julien Laganier'; [e-mail]
>>>>>>>>> Subject: RE: [MEXT] re-direction attack on MCoA
>>>>>>>>> On Wed, 30 Jan 2008, Benjamin Lim wrote:
>>>>>>>>>> All in all, what I am trying to say is that tracing only
>>>>>>>>>> limits the
>>>>>>>>>> effect of the attack from escalating further and not
>>>>>>>>>> preventing it.
>>>>>>>>> => which (again) also perfectly applies to a single CoA.
>>>>>>>>> Regards,
>>>>>>>>> Wassim H.
>>>>>>>>> _______________________________________________
>>>>>>>>> MEXT mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>>>>>> _______________________________________________
>>>>>>>> MEXT mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>>>> _______________________________________________
>>>>>> MEXT mailing list
>>>>>> [e-mail]
>>>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>>>
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/mext
>>>
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/mext
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/mext
>>>
>>
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/mext
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/mext
From [e-mail]  Fri Feb  1 10:15:15 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9599928C169;
	Fri,  1 Feb 2008 10:15:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.762
X-Spam-Level: 
X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id jDZooEDgnCjM; Fri,  1 Feb 2008 10:15:14 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 705103A693A;
	Fri,  1 Feb 2008 10:15:14 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 30F0B3A69B2
	for <[e-mail]>; Fri,  1 Feb 2008 10:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id LatYHeQOFF10 for <[e-mail]>;
	Fri,  1 Feb 2008 10:15:12 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132])
	by core3.amsl.com (Postfix) with ESMTP id 4A8D93A6930
	for <[e-mail]>; Fri,  1 Feb 2008 10:13:49 -0800 (PST)
Received: from chelo-it-uc3m-es.it.uc3m.es (chelo-it-uc3m-es.it.uc3m.es 
	[163.117.139.76])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No
	client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 
	A2B822EBD92;Fri,  1 Feb 2008 19:15:23 +0100 (CET)
Message-Id: <[e-mail]>
From: marcelo bagnulo braun <[e-mail]>
To: [e-mail]
Mime-Version: 1.0 (Apple Message framework v915)
Date: Fri, 1 Feb 2008 19:15:22 +0100
X-Mailer: Apple Mail (2.915)
X-imss-version: 2.049
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-6.9168 TC:1F TRN:10 TV:5.0.1023(15704.000)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Cc: Julien Laganier <[e-mail]>
Subject: [MEXT] MEXT review of Diameter Mobile IPv6: Support for Network
	Access Server to Diameter Server Interaction draft
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/mext>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/mext>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Hi,

i would like to request feedback from the MEXT community on the  
following draft

Diameter Mobile IPv6: Support for Network Access Server to Diameter  
Server Interaction
draft-ietf-dime-mip6-integrated-07.txt

http://tools.ietf.org/html/draft-ietf-dime-mip6-integrated-07

Even though this is not a MEXT document, it is clearly MIP6 related,  
so it would be important that MEXT WG feel comfortable with it.

Thanks, marcelo
_______________________________________________
MEXT mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/mext