Subject: Re: Home Address Option Threat (was: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt)

From: "Venkata Jagana" <[email-masked]>
Date: Mon, 29 Oct 2001 12:00:49 -0800

Hello James,

> I think there may be an easy response to this. It requires 1) a secure L2
so
> that a malicious MN can't set it's L2 address arbitrarially, and > 2)
that an
> AR not route any packets from a MN that has not successfully done
Neighbor
> Discovery and for which the AR has a valid IP adress to L2 address
binding
> in its neighbor cache.

The issue is not the 'src' CoA address but it is the home address set
by a malicious node in an outgoing IPv6 packet. Who can prevent any node
from setting any valid home address in a packet as long as the src COA is
address is valid under ingress-filtering enabled network and the
problem mounts even further with packets originating from the malicious
nodes where no ingress filtering is enabled at all. In fact, the validation
at CN though should be done based on the home addres in the packet but
not on the CoA address which is arbitrary for the MNs visiting foreign
nodes.

I would consider this problem related to the receiving side rather than to
the sending side. It is hard to control on the sending side because
there are always unprotected networks from where these malicious nodes
can send packets that can disturb the normal flow.

Thanks,
Venkat

----- Original Message -----
From: "Venkata Jagana" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 26, 2001 5:29 PM
Subject: Re: [mobile-ip] Last Call Comments on
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01

.txt

>
>
> Hello Alper,
>
> What a coincidence! I am little bit late in sending out the exactly
> similar thought that I have on this security hole and the corresponding
> enhancement.
>
> In fact, I believe, the malicious node don't even need to know the CoA
> of MN and the home address is more than sufficient for it to send a
> packet with arbitrary src address in the packet to CN. As per
> the current MIpv6 draft, CN  would have to simply replace the 'src'
> address of IPv6 packet by the home address in the home address option
> in the incoming packet without any further validations and this is a
> problem.
>
> The solution, that I have in my mind, can be simply to look at the
> CN's binding cache upon receipt of incoming packet and validate that
> 'src and home address' of the packet matches with CN's CoA <-> Home
> Address binding before accepting it for further processing. In fact, this
> binding cache is already consulted for outgoing packets and it needs
> to be done for incoming packets as well in order to address this
> security concern and so, this may not be a real overhead since it is
> a simple lookup. However, this solution may not really work well in
> case where the malicious node somehow steals both CoA and Home address
> of MN and I guess that's always an issue anyway.
>
>
> Thanks,
> Venkat
>
> ----------------------------------------------------------------
> Venkata R Jagana
> IBM Linux Technology Centre, Beaverton
> [email-masked]
> Tel: (503) 578 3430 T/L 775-3430
>
>
> "Alper Yegin" <[email-masked]>@sunroof.eng.sun.com on
10/26/2001
> 04:53:55 PM
>
> Please respond to [email-masked]
>
> Sent by:  [email-masked]
>
>
> To:   <[email-masked]>
> cc:
> Subject:  Re: [mobile-ip] Last Call Comments on
>
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01

.txt
>
>
> Hello,
>
> I know I'm late for the last call. But nevertheless I'd like to identify
a
> new security issue
> with Mobile IPv6. Please take a look at this and comment....
>
> Home address option of Mobile IPv6 gives the flexibility to use any IP
> address as the source
> address of a packet and send it to a receipent (a correspondent node).
And
> the correspondent
> node should be able to process home address option to figure out the true
> end point of this
> communication. By using this option, a node can use any arbitrary IP
> address
> as the source
> address of outgoing packets, and be able to maintain end2end connection
> with
> a peer.
>
> This can be exploited by malicious nodes to impersonate other nodes, as
far
> as the routers
> along the path are concerned.
>
> Any mechanism that relies on the source IP address of a packet can be
> fooled
> by using an
> acceptable source IP address (like one borrowed from a legitimate node)
and
> carrying the
> real source address in the home address option.
>
> For example, a flow is (or proposed to be?) identified by the source
> address
> and the flow
> info of an IPv6 packet. If the malicious node can learn these two fields
of
> a legitimate packet, it can
> start using them in its own packets. Therefore stealing QoS established
for
> another device (along
> the common path).
>
> So, why do we think there's something new here. Afterall, even with IPv4,
a
> device can steal
> some other device's IP address and use it. But.... if it does so, the
> correspondent node would
> think that this packet is coming from the legitimate device, therefore
any
> correspondence will
> be directed at the legitimate device. And hence, malicious node cannot
> enjoy
> a end2end
> communication.
>
> With IPv6 and home address option, the packets from the malicious node
look
> like they are from
> a legitimate node to all the routers along the path (same as in IPv4)
and
> when arrived at the
> correspondent node they reveal their true sender (this is new!).
>
> A correspondent node receiving such packets won't know what's going on.
And
> nothing special
> on correspondent node is expected for this to work (except a correct
> implementation of home
> address option processing :)
>
> First solution that comes to mind would be to expect protocols to check
for
> home address
> option in addition to source address, but that is not desirable as it is
> costly.
>
> What do people think about this issue?
>
> (I might not be able to follow rest of the discussion for a week. I'll be
> out of town. But I'm sending
> this now, so that the discussion is not delayed).
>
> alper
> NTT DoCoMo USA Labs
>
>
>
>
>
>
>