Subject: [NSIS] RE: GIST Responder Cookie Generation

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 10 Nov 2005 23:28:36 -0000

hi roland,

the attack method i am thinking of is:

- node A sends a valid Query (from its real address), but does
not follow up with a Confirm
- at the same time, node A sends many valid Queries (from forged
addresses)

at this point, node A knows some valid liveness data (from the
Response to the first Query), but the 'victim' node has no idea
about the location of node A, since it has no idea which Query
was the useful one. (And it is probably trying to not remember
information about Query messages anyway.)

now node A floods the victim with Confirm messages from forged
source addresses. They have valid liveness data.

i don't see an easy defence against such an attack.

r.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 10 November 2005 15:10
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: GIST Responder Cookie Generation
> 
> 
> Hi Robert,
> 
> 
> > i've added some text on this to the relevant section in 8.5:
> 
> [and this is a quite good proposal...]
> 
> >   "To support the validation simplicity requirement, the 
> Responder can
> >    check the liveness data to filter out some blind 
> (flooding) attacks
> >    before beginning any cryptographic cookie verification.  
> To support
> >    this usage, the liveness data must be carried in the 
> clear and not be
> >    easily guessable; this rules out the timestamp approach, 
> and suggests
> >    the use of sequence of secrets with the liveness data 
> identifying the
> >    position in the sequence.  The rollover frequency of the 
> secret must
> >    be high enough that the secret cannot be brute-forced during its
> 
> ...and thus the secret must be long enough, too
> 
> >    lifetime.  Note that any node can use a Query to 
> discover the current
> >    liveness data, so it remains hard to defend against sophisticated
> >    attacks which disguise such 'probes' within a flood of 
> Queries from
> >    forged source addresses.  Therefore, it remains 
> important to use an
> 
> Nodes that send queries from spoofed source addresses will 
> not succeed in
> discovering the liveness data, so I'm a little bit confused here.
> If an attacker has the liveness data, he can send a lot of Confirms
> whose cookies must be checked. In this case the hash function must be
> efficient in order to avoid an attack on CPU resources. An attack
> on state resources by sending a lot of Confirms will still not be
> possible.
> 
> >    efficient hashing mechanism or equivalent."
> 
> > So, at the moment I think the best we get from this is some partial 
> > protection (because I don't see a way to prevent an 
> attacker extracting
> 
> Yep.
> 
> > valid cleartext liveness data with a Query). I think it is 
> useful, but
> 
> No, there is no way to prevent that. But I think this is probably not
> a serious problem since the attacking node must be reachable.
> In summary we have two lines of defense:
> 1. cookies against attackers that try to exhaust state resources
>    by sending from spoofed addresses (also a blind attacker)
> 2. liveness data against blind attacks trying to exhaust CPU resources
>    by letting the responder perform cookie validity checks for
>    confirm messages.
> 
> 
> > we still need to have fast hash (or whatever) verification 
> as part of
> > the requirement.
> > 
> > (unless someone can think of a better way ...)
> 
> Yes, input welcome.
> 
> Regards,
>  Roland
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Fri, 11 Nov 2005 01:22:01 +0100

Hi Robert,

> the attack method i am thinking of is:

thanks for explaining this in more detail, maybe I'm up too late now... :-)

> not follow up with a Confirm

Ok.

> - at the same time, node A sends many valid Queries (from forged

Why is this required?

Yep.

> information about Query messages anyway.)

I assume the latter case, i.e. late state installation.

> i don't see an easy defence against such an attack.

You are right. In this case, however, only CPU resources
are consumed by hashing PDU data and the secret. That's why
you require a fast cookie check function. Anyway no state
gets installed. This attack can be detected though, because
you get a high number of invalid confirms with correct liveness
data. In this case you
can increase the generation rate of the secrets (this is
also mentioned in the ikev2 draft as "if under attack" IIRC).

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Fri, 11 Nov 2005 09:20:04 +0100

Hi,

>>- at the same time, node A sends many valid Queries (from forged

After some sleep things are becoming clearer ;-)
You mean that node A is hiding its real address in the bulk
of Queries with spoofed addresses => some kind of masquerading.
Node A can even try to guess the rollover rate if
it sends several Queries from its real address between
a bulk of spoofed Queries.

Regards,
 Roland