Subject: Re: Fw: [mobile-ip] Unresolved issue #3: BA, BR authentication?

From: Jari Arkko <[email-masked]>
Date: Sun, 14 Apr 2002 19:19:36 +0300

Tuomas,

Thanks for commenting on this, I appreciate your view on this
very much. Some discussion below:

> I do not like the BA/BR authentication. First, do they need 
> to be authenticated? Second, the protocol is difficult to 
> understand and analyze.

So, we need to figure out if there is a serious enough vulnerability
without BA/BR authentication.

The attack we had in mind was a DoS attack where the attacker
bombs the MN with bogus HoTs or CoTs. In the plain RR protocol
these can be sent from anywhere in the Internet, and the MN has
no way of distinguishing them from each real ones. Granted, the
attacker has to be sending these messages all the time unless he
knows when RR is initiated. As a result of the attack, BU fails.
This failure is though noticeable in the form of an error code in
the BA. As a result, the MN may not get RO but at least it can
still keep on doing bidirectional tunneling.

In a more serious variant of the attack the attacker spoofs also
successful BAs. If the MN happens to believe them, it starts RO
while the real CN doesn't have a BCE, leading to at least some
packets being blackholed. It may be possible to survive this given
that there most likely isn't any forward progress on application
layer and the BM messages keep coming to the MN. However, the MN
may need some intelligence in getting out of the attack situation
and staying with bidirectional tunneling while the attacker continues
the attack.

Is this serious enough? I'm not sure!

> However, it will be difficult to explain exactly why the BA/BR 
> authentication works and to quantify how strong it is compared 
> to the BU authentication.

The essence of RR is that nodes who are not on the CN-HA path
can't get to the cookies and hence can't authenticate. The original
intention of the BA/BR authentication was to produce a similar level
of authentication for the responses. In other words, if you don't
see the cookie from the MN you can't claim to be sending a response
either.

However, the basic RR protocol is complicated withe the Kcn and other
details mainly due to the need to keep CN stateless. This isn't necessary
when talking about responses to individual requests to the CN.

> To get exactly the same strength of authentication for the 
> BA/BR as for the BU, the BA/BR should be authenticated with 
> MAC_Kba where Kba= H(C0 | C1), not with MAC_Kbu.

How about this: we don't provide any authentication of the CN
in the sense that all the messages be tied to each other in some
manner. But we provide a simple send cookie - return cookie for
each of the request - response pairs in the protocol. We also delete
the MAC field from the BA and BR, and only keep the response cookie.

This limits the attacks to those nodes who are on the path to see
the cookies from the MN, but does not add any MAC calculations,
encryption, or CN state requirements. Also, I think that would
make CN and MN authentication separate, so analysis should be easier.

Comments?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Apr 2002 16:27:59 -0700

Jari,

> Is this serious enough? I'm not sure!

A question about the serious variant of the attack. When this 
attacker spoofs the successful BA, has the MN sent out another BU?
If no, then there is no problem. The spoofed BA is dropped because 
there is no corresponding pending BU. If yes, then the sequence 
numbers dont match. The BA is dropped.

If the attacker was able to guess the right sequence number he 
still cant use it. This is because the MAC_Kbu in the BA wont be 
correct and the spoofed BA is dropped.

So the scenario where the MN believes the CN has a BCE while the
CN does not, cannot happen. Please let me know if I am missing 
something.

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Apr 2002 16:55:17 +0300

> numbers dont match. The BA is dropped.

This is an excellent observation! The sequence number works in
this case as a sort of a weak cookie, which as you point out,
the attacker doesn't know. Perhaps this could be enough.

Question: in BR, we don't have a sequence number. If the BR
is more like a binding refresh request, should we add the sequence
number also there?

> correct and the spoofed BA is dropped.

We were discussing removing MAC_Kbu from the BA, and replacing it with
a simple returned cookie. It may now turn out that the sequence number
may be a sufficient cookie.

Jari

---

From: Brian Haley <[email-masked]>
Date: Thu, 18 Apr 2002 12:30:30 -0400

> is more like a binding refresh request, should we add the sequence

We can use the Unique Identifier for this, right?  Section 5.2.4:

  "The Unique Identifier parameter is valid only in Binding Request and
   Binding Update messages.  The Unique Identifier field contains a
   16-bit value that serves to uniquely identify a Binding Request among
   those sent by this Source Address, and to allow the Binding Update
   to identify the specific Binding Request to which it responds."

It goes on to say it's useful for renumbering, but you've found another
use for it.

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 18 Apr 2002 09:44:09 -0700

> the attacker doesn't know. Perhaps this could be enough.

Great! I think it is enough.

> is more like a binding refresh request, should we add the sequence

Maybe we should look at what a spoofed BR can cause. At the 
worst it makes the MN go through RR/BU procedure with a CN.
Perhaps, we could just do some rate limitation at the MN 
(Charlie's idea). It does not process more than a certain 
number of BRs for a period of X duration. IMO, BR does not 
need any protection.

> may be a sufficient cookie.

So, Tuomas Aura's option (3) is not needed now (see Tuomas's 
mail on this subject). In fact (1) is much better than 
option (3) that he was proposing (because cookie C2 is not 
needed) 

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Apr 2002 08:42:51 +0300

Jari Arkko wrote:

> The sequence number works in

An update: It was pointed out to me by Tuomas that we don't want to repeat
the problems we have with TCP sequence numbers as cookies. Sequence
numbers are too predictable. Instead, a cookie should be added.

And it does look like the approach #3 is preferred by many folks,
on the basis of giving some protection but still being easily understood
and analyzed.

The one attack that this doesn't protect against is someone on the
visited network who can see the cleartext C2 going to the CN, and could
spoof an answer BA. However, an attacker on this link could also do lots
of other bad things, such as sending TCP RSTs on the traffic between
the MN and the CN.

> is more like a binding refresh request, should we add the sequence

One idea is that since we have a very BR-like functionality already in
BM, and since there is no way we can authenticate a BM, we should just merge
this functionality and not have any authentication.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 19 Apr 2002 10:05:51 -0700

> numbers are too predictable. Instead, a cookie should be added.

The assumption in my earlier mail was that the sequence number
in the binding ack was covered by a MAC. This MAC was generated
using Kbu. This is from your proposal at
http://www.piuha.net/~jarkko/publications/mipv6/issues/issue3.txt.
I was just simplifying that by eliminating C2. So even if the 
attacker guesses the sequence number, he still cant generate the 
MAC.

> And it does look like the approach #3 is preferred by many folks,

private emails?? I havent seen anything on the mailing list.

> on the basis of giving some protection but still being easily understood

But approach #1 is better than #3. I hope you agree with that.

> this functionality and not have any authentication.

Agree with that.

regards
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 19 Apr 2002 10:15:27 -0700

Sorry for following up on my own mail....

> > this functionality and not have any authentication.

I missed this. I do not understand what you mean by "merging 
this functionality?" Are you thinking of eliminating BR and 
adding another code to the BM message? I hope you didnt mean 
that. The agree was only for BR not needing any authentication

Vijay