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 03:06:24 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 243D33A691A
	for <[e-mail]>; Fri,  1 Feb 2008 03:06:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 45.585
X-Spam-Level: *********************************************
X-Spam-Status: Yes, scoreE.585 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, NORMAL_HTTP_TO_IP=0.001,
	RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5,
	RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905,
	RCVD_IN_XBL=3.033, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001,
	TVD_FINGER_02=2.134, URIBL_BLACK , URIBL_WS_SURBL]
X-Spam-Report:
 *  3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
 *      [score: 1.0000]
 *  1.5 FH_RELAY_NODNS We could not determine your Reverse DNS
 *  0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE
 *  2.1 TVD_FINGER_02 TVD_FINGER_02
 *  0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL
 *  1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
 *      above 50%
 *      [cf: 100]
 *  0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/)
 *  0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
 *      [cf: 100]
 *   20 URIBL_BLACK Contains an URL listed in the URIBL blacklist
 *      [URIs: 220.87.253.50]
 *   10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
 *      [URIs: 220.87.253.50]
 *  0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
 *      [122.161.79.50 listed in zen.spamhaus.org]
 *  3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
 *  2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
 *      [Blocked - see <http://www.spamcop.net/bl.shtml?122.161.79.50>]
 *  0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS
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 gqI-9v21dSVE for <[e-mail]>;
	Fri,  1 Feb 2008 03:06:23 -0800 (PST)
Received: from ABTS-NCR-Dynamic-050.79.161.122.airtelbroadband.in (unknown [122.161.79.50])
	by core3.amsl.com (Postfix) with SMTP id 7D45A3A68F2
	for <[e-mail]>; Fri,  1 Feb 2008 03:06:21 -0800 (PST)
Received: from bzwp ([157.55.43.105])
	by ABTS-NCR-Dynamic-050.79.161.122.airtelbroadband.in (8.13.3/8.13.3) with SMTP id m11BApcE076167;
	Fri, 1 Feb 2008 16:40:51 +0530
Message-ID: <001801c864c2$b83d3070$692b379d@bzwp>
From: <[e-mail]>
To: <[e-mail]>
Subject: ***SPAM*** 45.585 (5) Doctors endorse this miracle formula!
Date: Fri, 1 Feb 2008 16:38:05 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506

Convenient and private ordering! http://220.87.253.50/ok/