Subject: [mobile-ip] MIPv6: RR replay detection

From: "Greg O'Shea" <[email-masked]>
Date: Wed, 4 Dec 2002 18:26:02 -0000

The correspondent node can, for instance, change the nonce
   often enough to ensure that the nonces used when removed entries
   were created are no longer valid.   If many such deletions occur
   the correspondent node can batch them together to avoid having to
   increment the nonce index too often.[5.2.8]

If the nonces are global (supplied to multiple MN) then I don't see how
this works: it seems to suggest invalidating all nonces with age greater
or equal to the nonce you want to delete. But the nonce you want to
delete could be arbitrary recent, e.g. because an MN sent a delete
request immediately after obtaining new nonces, at which point there
could be many MN in possession of older nonces that should survive.

If you delete those two sentences then the remainder of 5.2.8 makes
sense (to me).

Greg

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 04 Dec 2002 10:43:55 -0800

Hello Greg,

As far as I understand it, the correspondent node could have
three or two dozen nonces active at the same time.  The
number of valid nonces (each selectable by a distinct
nonce index) doesn't have to so restricted.  The point of
it anyway is to disable the possibility for a denial of service
attack which would be possible if the number of nonces
depended on the number of HoTI or CoTI messages
received.

If I have somehow misunderstood this, then I would like
to raise an issue in order to make the specification work
this way.

Regards,
Charlie P.

Greg O'Shea wrote:

> If the nonces are global (supplied to multiple MN) then I don't see
> how this works: it seems to suggest invalidating all nonces with age
> greater or equal to the nonce you want to delete. But the nonce you
> want to delete could be arbitrary recent, e.g. because an MN sent a
> delete request immediately after obtaining new nonces, at which point
> there could be many MN in possession of older nonces that should
> survive.
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Dec 2002 22:04:23 +0200

Greg,

We have to make sure that a replay attack can't be launched. There's two
potential ways of achieving this:

   1) Keeping a 'ghost' BCE entry around even after deletion so that we
      can make sure the same tokens are not reused. This requires memory.

   2) Letting nonce indices expire sooner. Yes, these could be quite recent
      as you point out, so this would hurt the MNs trying to send BUs at this
      time. OTOH, no memory is needed.

What 5.2.8 tries to suggest is the two potential techniques above. While
you (and me) do not like deleting too recent nonces, perhaps you can live
with the CN's freedom to choose either technique? Or would you like to require
only the first technique to be used?

If you can live with both techniques then we need a clarification of the
text in 5.2.8. The current text seems to say only the second technique is
appropriate. If I change "can, for instance, change the nonce" to "could also
change the nonce", would that be better?

Jari