Subject: [mobile-ip] RR Replay attack question

From: Brian Haley <[email-masked]>
Date: Thu, 10 Apr 2003 19:04:27 -0400

I've been trying to understand the last paragraph in this CN section
a little better:

 9.5.3 Requests to Delete a Binding

   This section describes the processing of a valid Binding Update that
   requests a node to delete a mobile node's binding from its Binding
   Cache, for which the Home Registration (H) bit is not set in the
   Binding Update.

   Any existing binding for the mobile node MUST be deleted.  A Binding
   Cache entry for the mobile node MUST NOT be created in response to
   receiving the Binding Update.

   If the Binding Cache entry was created by use of return routability
   nonces, the correspondent node MUST ensure that the same nonces are
   not used again with the particular home and care-of address.  If both
   nonces are still valid, the correspondent node has to remember the
   particular combination of nonce indexes, addresses, and sequence
   number as illegal, until at least one of the nonces has become too
   old.

I believe it's referring to this section:

 5.2.8 Preventing Replay Attacks

   The return routability procedure also protects the participants
   against replayed Binding Updates through the use of the sequence
   number and a MAC.  Care must be taken when removing bindings at the
   correspondent node, however.  Correspondent nodes must retain
   bindings and the associated sequence number information at least as
   long as the nonces used in the authorization of the binding are still
   valid.  Alternatively, if memory is very constrained, the
   correspondent node MAY invalidate the nonces that were used for the
   binding being deleted (or some larger group of nonces that they
   belong to).  This may, however, impact the ability to accept Binding
   Updates from mobile nodes that have recently received keygen tokens.
   This alternative is therefore recommended only as a last measure.

So if I understand this right, when a CN deletes a binding, it must
either 1) remember it's state; or 2) invalidate the nonces that were used
to send it (there was a thread on the archives that might be relevant
http://playground.sun.com/pub/mobile-ip/WG-archive/current/frm00041.html).
I don't really like either option.

Can someone explain a scenario in which a replay attack could be
launched successfully?  If a MN deletes a CN binding, why would we
care if someone replayed that packet since it won't affect the
binding cache since there is no binding any more?

I believe TAHI did have a test for this at Connectathon too.

Thanks,

-Brian

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 10 Apr 2003 16:21:43 -0700

> I don't really like either option.

Yes, in our implementation we actually do #1. We turn the BCE into a ghost
entry with a 0 lifetime. It gets cleaned up eventually (i.e. after enough
time elapses to prevent a replay attack), but while it exists it prevents
the replay attack scenario.

> binding cache since there is no binding any more?

If a MN returns home, it asks the CN to delete its binding. Let's say the MN
had moved recently, so there is a copy of a BU somewhere in the network that
the MN sent in the past few minutes when it updated its CoA. If someone
could replay this BU to the CN (or perhaps if it was a BU retransmission,
and just happened to be delayed somewhere in the network), the BU still has
valid nonce indexes (assuming the CN didn't implement #2 above) so the CN
will accept it and create a binding. The MN has returned home, however, and
if it sends packets to the CN (it probably will, since that's why it had an
active binding with the CN before it returned home) and the CN responds, the
CN will route the response packets to a foreign link, not to the MN's home
link, and then the MN won't receive those packets. Probably the CN will get
an ICMPv6 Destination Unreachable error, but that could take a minute.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Apr 2003 08:09:31 +0300

> binding cache since there is no binding any more?

If the nonces are still valid, BAD will be correct and the
BU looks authentic. And since the BCE is gone, we can't claim
that the sequence number has already been used. As a result,
CN accepts the BU and the traffic goes to the MN's old location.

Jari

---

From: Brian Haley <[email-masked]>
Date: Fri, 11 Apr 2003 08:43:23 -0400

> CN accepts the BU and the traffic goes to the MN's old location.

Thanks Jari and Ed for the explanation, it's becoming clearer.

So if an attacker has captured the last two BU's to a CN, one with
lifetime > 0, one with lifetime == 0, it can try and replay either.
But Section 9.5.3 mentions saving the sequence #:

  "If both
   old."

Or do we only care about the sequence # in the binding deletion?
But replaying a deletion doesn't really get an attacker anywhere,
it just makes the CN send future packets to the MN home address,
aren't we interested more in the sequence # that added/updated
the binding?

I guess I don't see why this is that important since a MN->HA BU
can also be replayed:

  "However, IPsec can easily provide replay protection only if dynamic
   security association establishment is used."

but we don't protect against that, just warn it could happen.

Thanks,

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Apr 2003 17:33:45 +0300

>    number as illegal, until at least one of the nonces has become too

Yes. This is because either you have to keep state for a short period
of time (remember the sequence number) or make the nonces invalid.

> Or do we only care about the sequence # in the binding deletion?

We do, but if you remember all three then you can delete your
state when the nonces become invalid through the usual process
of periodically changing them.

The implementation would be something like keeping "ghost" BCE
entries around after deletion, and removing these entries when
the associated nonces expire. If space runs really low, speed
up the nonce expiry time.

> aren't we interested more in the sequence # that added/updated

Yes. That number would be N-1 and also considered old by the CN.

> but we don't protect against that, just warn it could happen.

That's right. Maybe its because its relatively easy to protect
against this in RR, while for IPsec - IKE its only possible if
you do IKE.

(Also FYI: if the HA doesn't reboot and forget the current sequence
number, the MIPv6 layer sequence numbers  will be able to
protect against replay attacks from the last 2^15 BUs.)

Note that for th

Jari

---

From: Brian Haley <[email-masked]>
Date: Fri, 25 Apr 2003 13:53:57 -0400

>    number as illegal, until at least one of the nonces has become too

Ok.  I've investigated changing our code to support this, but I don't
believe the draft gives enough information on what you should do with
a replayed BU.

If I have a ghost entry and get a replay, I can do one of the following:

1. Send a BAck because the sequence number is invalid (code 135).  But if
	we do this the MN will assume we have a binding, and we really
	don't - if it tried to delete it we would send an error (code 128).
	This might be ok since a *real* MN would send a BU with a valid
	sequence number.

2. Send a BAck with a nonce expired error, if applicable (codes 136, 137, 138).
	But the MN could then do RR and possibly get the exact same nonce
	indeces it just tried.

3. Silently drop the packet.

I would assume we would want to send something, since this might just be
a misbehaving MN, or do we process the BU as Section 9.5.1 states, even
though we really don't have a current binding?

It wouldn't be good if everyone implemented a standard differently :)

-Brian

---

From: "Bryan Wang" <[email-masked]>
Date: Mon, 28 Apr 2003 09:42:20 -0700

HI Brian,

Thanks for pointing this out. We took the approach #1 in our implementation.
A reply always have invalid seqence number, we'll always catch it, and as
you said, a good and bug free MN would not use the same sequence number.

When one of the nonce expires, you would remove all gohst entries used that
nonce, therefore, #2 will not happen.

Thanks,
Bryan Wang
Elmic Systems

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 28 Apr 2003 09:49:43 -0700

> A reply always have invalid seqence number, we'll always catch it, and as

reply => replay ;)

"A replay always has an invalid sequence number, ..."