Subject: [Hipsec] MM: Using UPDATEs for RR

From: [email-masked] (Henderson, Thomas R)
Date: Thu Apr 29 18:44:01 2004

Yes, it seems that RR should rely on an unguessable nonce exchange.

Even having the NES with REA doesn't seem to fully protect:

1. MN sends CN a bogus address REA + NES in UPDATE request.
2. CN sends MN an UPDATE-response to new bogus address.
3. CN sends MN an UPDATE-request with NES to new bogus address.
4. MN waits a bit to give CN time to send the UPDATE
    request, guesses the update ID, and
      sends an UPDATE response to the CN.
5. Response looks OK to CN, so it starts using the
      bogus address.  MN can't use CN's new inbound SPI, but
      it may not need to if CN is the one spewing data

One way to plug this would be to require UPDATE-request NES to be=20
echoed in UPDATE-reply, since SPI has suitable randomness properties.
This pretty much forces NES to be used with REA. Or else define some=20
other nonce mechanism for RR.

Tom

> -----Original Message-----
> From: Jonathan Wood [mailto:[email-masked]]=20
> Sent: Thursday, April 29, 2004 4:02 PM
> To: [email-masked]
> Subject: [Hipsec] MM: Using UPDATEs for RR
>=20
>=20
>=20
> Hi,
>=20
> I have a question about using UPDATEs without
> NES parameters (i.e. containing only the UPDATE-ID
> parameter) for RR. Is this method open to an attack
> where the attacker can (easily) guess the update ID
> and generate a valid UPDATE response? Since the
> update ID increases by one each time and starts at
> 1, it is easy to guess.
>=20
> For example:
>=20
> 1. MN sends CN a bogus address REA.
> 2. Peer sends MN an UPDATE request with the
>      UPDATE_ID parameter (without a NES) to
>      the bogus address.
> 3. MN waits a bit to give CN time to send the UPDATE
>      request, guesses the update ID, and
>      sends an UPDATE response to the CN.
> 4. Response looks OK to CN, so it starts using the
>      bogus address.
>=20
> Or am I missing something?
>=20
> Jon
>=20
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>=20

---

From: [email-masked] (Jonathan Wood)
Date: Fri Apr 30 13:16:00 2004

On Apr 29, 2004, at 4:34 PM, Henderson, Thomas R wrote:

>
> One way to plug this would be to require UPDATE-request NES to be
> This pretty much forces NES to be used with REA. Or else define some

How about having the CN send a echo request tlv in the update reply,
and having the MN respond with an update reply (to the update reply)
containing an echo response? The echo can contain the nonce.

This way, you could also compress the update reply and update 
request(RR)
from the CN into one message. The drawback is that it does make the
protocol a bit messier...

Jon