Subject: Re: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt

From: "Alper Yegin" <[email-masked]>
Date: Mon, 5 Nov 2001 16:35:27 -0800

Hi Charlie,

I was away from my e-mail for a week. Let me respond to the messages in this
thread.

> > This can be exploited by malicious nodes to impersonate other nodes, as
far
> > as the routers along the path are concerned.
>
> The point of the option is to apply a topologically correct source
> address.  Routers aren't checking to see _who_ is sending the
> packet.  They're checking to see if the address matches a reasonable
> prefix.  I don't think it makes sense to worry about a malicious node
> impersonating a node, when the entity it is fooling doesn't care anyway.
>

But as I was trying to illustrate, routers would care about the sender, if
they
want to identify flows for QoS purposes.

> >
> >
> >
> > Aaddress 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).
>
> It is an interesting problem about whether a flow label needs to be
> interpreted according to the destination IP address or the home
> address.  It seems wrong to try to make the intermediate
> routers parse the home address option.  I reckon that there

I wish we didn't have to. But the true end-point of a connection
can only be identified if we also look into home address option.
Sender can put any address in the source address field, as long
as there's a home address option. Receiver would toss away
the source address, it has no significance.

> should be a QoS feature transfer, which includes something
> about new and old flow labels, to handle the flow over a tunnel
> between access routers while the new care-of address gets to
> be associated with the flow.  We've been puzzling over this a
> little bit already in our group, but it depends on a lot of things that
> are currently unknown.
>
> It's not a security problem, though...
>
> >
>
> > 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!).
>
> It would be exactly like the packets came from the home network.... right?

Right.

> And so that's exactly what we are trying to accomplish!

Right :) But what we don't want to accomplish is to give malicious nodes a
new
(and legitimate) tool to hide their identity. Unless routers
also check this new field, this can be a problem as I illustrated in my
example.

>
> > 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.
>
> Why do you want to do this?

Please see my example. Malicious node can "borrow" a legitimate IP address
and flow info to use for its own traffic.

> Which protocols should check?  Surely not
> the protocols running on the routers...?

Routers, who implement a QoS protocol and identify flows by looking
at packets' source address and flow info field would have to be concerned.

> Regards,
> Charlie P.

alper