Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options

From: Pekka Nikander <[email-masked]>
Date: Fri, 01 Mar 2002 11:33:55 +0200

Rajeev Koodli wrote:
> Since  packet loss when the MN sends HAO when
 > there is no entry in the CN is the issue,
> let me propose the following: the CN does not
 > drop those packets. Instead, it does not
> tag the first few packets until it moves to
 > tagging state. So, the downside is the receiver
> does not know the source for say 3 packets. What
 > do you think ?

Looks quite bad from the DDoS reflection point of view.
If I am an attacker, able to spoof addresses, and
therefore subject to i-trace etc. (which is the
reason for the tagging), I can launch an easy but not
very good attack:

   1. I send one packet to the CN, with no
      HAO and src=HaO -> CN goes to no-tagging state.
      This packet may trigger i-trace, but maybe I
      can get somebody else to send the packet.

   2. I send a few packets, with HAO=HaO, to the CN.
      The CN replies to these, with dst=HaO.
      The replies are not tagged, since the CN is
      in no-tagging state, and therefore the
      replies do not reveal me through i-trace etc.

   3. Repeat the cycle.

The practical effect of this attack is that I
can make the probablity of i-trace etc revealing
smaller than it otherwise could be.  But this is
just one way of defeating the purpose of tagging,
there are probably more effective ones.

Again:  From the security point of view, it is
important that *no* packets that are replies to
any packet containing HAO leave the CN towards
the HoA, unless they contain the tag.  If we
make an intentional hole into tagging, somebody
will find a way to (mis)use it, sooner or later.

I do not like approaches that compromize existing
security for the sake of an optimization that may
or may not be videly used and that does not
necessarily bring that much benefit.  Considering
the complexity of processing unvHAOs, how likely
is that somebody implements unvHAO processing
but not RR?  RR requires no hard crypto, no
complicated states, and only 1.5 RTT.

--Pekka

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 01 Mar 2002 09:06:34 -0800

Pekka,

I understand and I go back to the original proposal that
all responses to unverified HAO be tagged.

Here is a way to tackle the packet loss issue. The CN would
move to tagging state when it receives a packet with HAO
(and hence start tagging right away). However, if it receives a
packet without HAO but with HoA as source IP address,
it goes back to no-tagging state and resides in that state
until a timer (randomized) expires. This way, the MN's
packets with HAO will not be dropped regardless of the
state in which the CN is.

Regards,

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 1 Mar 2002 18:44:40 +0100 (CET)

> Yes. It appears that we are looking at the issue from slightly different
> angles. Since
> packet loss when the MN sends HAO when there is no entry in the CN is the
> issue, let me propose the following: the CN does not drop those packets.
> Instead, it does not
> tag the first few packets until it moves to tagging state. So, the downside
> is the receiver
> does not know the source for say 3 packets. What do you think ?

For security reasons I think the CN needs to tag conservatively i.e. it
is fine if it tags when it isn't needed.

Getting this behavior as well as making the tagging logic be robust against
packet loss and other ways the MN and CN can get out of synch is the hard
part.

I know one way to make it robust, but that ends up looking where much like a
BU exchange:
1b	MN(CoA) -> CN
2b	CN -< HN(Coa)
3	MN(CoA) -> CN	create unvHAO state please
4	CN -< HN(Coa)	state created with lifetime X

The 1b/2b exchange is there to prevent an attacker spoofing the source address
from filling the unvHAO cache.
The 3/4 exchange allows the MN to know that an entry was created
and when it will be expired (so that the MN can renew it explicitly).

The above is both secure and robust against packet loss as far as I understand.
But I don't see any benefit of doing it since it looks almost like doing RO.

> > I can't tell whether you agree with my point that the unvHAO logic
> > you've expressed is causing loss expansion in some cases where
> > packet loss will cause the unvHAO cache entry to time out causing packets
> > to be dropped by the CN.
> >
> 
> I agree. I might not agree with the rate of such occurrence. Also, if we can
> allow
> the CN to not drop those packets (say the CN is in a standby state before it
> moves
> to no-tagging state) then that might be a good compromise.

I don't see how you can do that and still not have holes.

> I mentioned this is useful (see below).. What if the BR is sent when the
> entry is created and it includes a lifetime field ?

That would help a bit (but it doesn't look like a BR any more but that is a 
detail). What if that BR is lost?
Should the CN send one for every unvHAO it receives? Should the CN indicate
that it wants to receive such a BR?

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 03 Mar 2002 09:57:56 +0200

> is fine if it tags when it isn't needed.

Not so simple.  As I argued in another message, *if* firewalls
drop tagged packets, tagging when not needed leads to nasty
denial-of-service attacks against stationary hosts.

Which brings forth an idea:  would it be possible to use some
variant of the "one bit" method to signal that a host using
a given address *is* a stationary host, and unvHAOs should not
be accepted for that address at all?  In any case, the bidding
down attack is most vicious against stationary hosts that do not
understand MIPv6 signalling at all.

I know this idea has lots of problems, but maybe somebody could
use the idea to develop something really useful.

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 4 Mar 2002 10:34:38 +0100 (CET)

> denial-of-service attacks against stationary hosts.

Yes, but failure to communicae is a security feature and not a security bug :-)
 From a strict security perspective conservative tagging is fine.
Making things actually work requires more than just considering the
security perspective.

So I agree that you need to consider the claimed desire to have firewalls
filter tagged packets, robustness in terms of the MN and CN getting
out of synch on the unvHAO state, etc.

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 04 Mar 2002 12:13:18 +0200

Erik,

This is nit picking but...

> From a strict security perspective conservative tagging is fine.

... the validity of the above statement depends on your definition
of security.  Some people, including me, tend to count availability
of services also as belonging to "security", even though resiliance
in the large goes beyound.

Thus, if a mechanism creates potential availability problems, i.e.
opens up new venues for denial-of-service, I would count it as
a security problem.  Thus, failure to communicate is not necessarily
a security feature, it can also be a security bug.  Especially, failure
to convey legitimate communication should be considered as an
availability bug, and therefore as a security bug.

:-) :-)

--Pekka