Subject: 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: Fri, 26 Oct 2001 18:29:22 -0700

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

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 27 Oct 2001 07:26:00 +0300

> Address binding before accepting it for further processing. In fact, this

If you did this, wouldn't it mean that Route Optimization is mandatory to use
in all Mobile IPv6 communications? This would be a big change. Also,
how would the first BU packet get validated by this rule?!

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sat, 27 Oct 2001 08:15:33 +0300 (EEST)

> of MN and I guess that's always an issue anyway.

AFAICS, most of theses issues were brought up and discussed somewhat
during the last two weeks.  Some description of the problem is at:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "James kempf" <[email-masked]>
Date: Mon, 29 Oct 2001 08:33:07 -0800

Alper and Venkata,

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. If the link shares these two characteristics, then it
should not be possible for a malicious  MN to steal the address of a benign
MN because the AR won't route any packets from the malicious MN. The AR just
needs to check whether the source address corresponds to a legitimate
binding in the neighbor cache.

            jak

----- 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

> of MN and I guess that's always an issue anyway.
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01
.txt

---

From: Michael Thomas <[email-masked]>
Date: Mon, 29 Oct 2001 08:43:11 -0800 (PST)

> binding in the neighbor cache.

   The AR only knows about its own prefixes, not
   the HA's prefixes. Unless there is some way for
   the HA to populate the AR with legitimate MN
   bindings of its home address, the AR will be
   clueless about this. In MIPv6, there is, in
   fact, no AR->HA communication so this is even
   more problematic.

	Mike

---

From: "James kempf" <[email-masked]>
Date: Mon, 29 Oct 2001 09:16:44 -0800

Mike,

By "done Neighbor Discovery" I was meaning Neighbor Discovery
for the CoA, which should be controlled by the access router.
Would that be sufficient?

            jak

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 29, 2001 8:43 AM
Subject: Home Address Option Threat (was: Re: [mobile-ip] Last Call Comments
on
.txt)

---

From: Michael Thomas <[email-masked]>
Date: Mon, 29 Oct 2001 09:23:01 -0800 (PST)

> Would that be sufficient?

   It would be sufficient to do ingress filtering on the
   CoA, which is not the same thing as doing ingress filtering
   on the home address option. The latter was the subject
   of this thread, right? The home address option was
   specifically created so that the source address would
   look topologically correct so that it would pass
   ingress filtering. It appears that it just moves the
   problem around though, which shouldn't be too surprising.

		  Mike