Subject: Re: [Hipsec] Conflicting text in RFC5201 - RFC5201-bis

From: Ari Keranen <[email-masked]>
Date: Wed, 09 Jun 2010 08:38:24 +0300

Hi,

On 05/26/2010 01:37 PM, Tobias Heer wrote:
> I have a question regarding some text in RFC5201 that conflicts with
> the crypto agility that we envisioned.  The new BEX will have to
> start the negotiations of the DH groups already in I1 to allow the
> Responder to pick a sensible DH group (there are simple
> countermeasures against downgrade attacks, too, so don't worry). 
> Therefore, the I1 becomes slightly more important than it was
> (although it stays unsigned and cheap).
> 
> 
> In Section 4.1 RFC5201 states:
> 
> ... 705          The Initiator first sends a trigger packet, I1, to
> the 706          Responder.  The packet contains the HIT of the
> Initiator 707          and possibly the HIT of the Responder, if it
> is known. 708          Moreover, it contains a list of Diffie Hellman
> Group IDs 709          supported by the Initiator.  Note 710
> that in some cases it may be possible to replace this trigger 711
> packet by some other form of a trigger, in which case the 712
> protocol starts with the Responder sending the R1 packet. ...
> 
> With the DH group negotiations already starting in I1 it becomes
> difficult to omit the I1 (you can do it but you lose DH crypto
> agility). Moreover, I doubt that omitting the I1 works well even
> without considering the DH group negotiations because some of the
> measures to keep the Responder stateless until I2 rely on having
> information from the I1 (IP address or HIT) for the puzzle/ opaque
> data field.
> 
> 
> My questions are: Is anyone using or does anyone intent to use this
> omission of the I1? Is there any specification on how to do it (at
> least this is the only place in 5201 where it is mentioned). Do we
> need this feature because there are cases where you cannot send an
> I1? And finally: can we live without that note?

In HIP BONE we have thought about using this feature for DoS protection 
(and perhaps also for making the BeX via overlay faster):

3.3.1. DoS Protection
[...]
    In an overlay scenario, there are multiple ways how this mechanism
    can be utilized within the overlay.  One possibility is to cache the
    pre-generated R1 packets within the overlay and let the overlay
    directly respond with R1s to I1s.  In that way the responder is not
    bothered at all until the initiator sends an I2 packet, with the
    puzzle solution.  Furthermore, a more sophisticated overlay could
    verify that an I2 packet has a correctly solved puzzle before
    forwarding the packet to the responder.

I think this is a useful feature, but since it's more of an optimization 
than something we rely on, if needed, we should be able to live without 
it too.

Cheers,
Ari

---

From: Tobias Heer <[email-masked]>
Date: Wed, 09 Jun 2010 13:01:21 +0200

Hello Ari,

Am 09.06.2010 um 07:38 schrieb Ari Keranen:

>> countermeasures against downgrade attacks, too, so don't worry). Therefore, the I1 becomes slightly more important than it was
> In HIP BONE we have thought about using this feature for DoS protection (and perhaps also for making the BeX via overlay faster):
> 
> 3.3.1. DoS Protection
> [...]
> I think this is a useful feature, but since it's more of an optimization than something we rely on, if needed, we should be able to live without it too.
> 
> 
have you considered René's proposal regarding the use of an I1-less BEX? The procedure of opportunistically responding with any DH group or a way of telling the preferred DH groups in a DHT packet could be options, right?

BR, 

Tobias

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: Ari Keranen <[email-masked]>
Date: Fri, 18 Jun 2010 15:20:43 +0300

Hi Tobias,

On 06/09/2010 02:01 PM, Tobias Heer wrote:
>>> I have a question regarding some text in RFC5201 that conflicts
>>> with the crypto agility that we envisioned.  The new BEX will
>>> have to start the negotiations of the DH groups already in I1 to
>>> allow the Responder to pick a sensible DH group (there are simple
>>> (although it stays unsigned and cheap). In Section 4.1 RFC5201
>>> states: ... 705          The Initiator first sends a trigger
>>> packet, I1, to the 706          Responder.  The packet contains
>>> the HIT of the Initiator 707          and possibly the HIT of the
>>> Responder, if it is known. 708          Moreover, it contains a
>>> list of Diffie Hellman Group IDs 709          supported by the
>>> Initiator.  Note 710 that in some cases it may be possible to
>>> replace this trigger 711 packet by some other form of a trigger,
>>> in which case the 712 protocol starts with the Responder sending
>>> the R1 packet. ... With the DH group negotiations already
>>> starting in I1 it becomes difficult to omit the I1 (you can do it
>>> but you lose DH crypto agility). Moreover, I doubt that omitting
>>> the I1 works well even without considering the DH group
>>> negotiations because some of the measures to keep the Responder
>>> stateless until I2 rely on having information from the I1 (IP
>>> address or HIT) for the puzzle/ opaque data field. My questions
>>> are: Is anyone using or does anyone intent to use this omission
>>> of the I1? Is there any specification on how to do it (at least
>>> this is the only place in 5201 where it is mentioned). Do we need
>>> this feature because there are cases where you cannot send an I1?
>>> And finally: can we live without that note?
>> In HIP BONE we have thought about using this feature for DoS
>> protection (and perhaps also for making the BeX via overlay
>> faster):
>> 
>> 3.3.1. DoS Protection [...] In an overlay scenario, there are
>> multiple ways how this mechanism can be utilized within the
>> overlay.  One possibility is to cache the pre-generated R1 packets
>> within the overlay and let the overlay directly respond with R1s to
>> I1s.  In that way the responder is not bothered at all until the
>> initiator sends an I2 packet, with the puzzle solution.
>> Furthermore, a more sophisticated overlay could verify that an I2
>> packet has a correctly solved puzzle before forwarding the packet
>> to the responder.
>> 
>> I think this is a useful feature, but since it's more of an
>> optimization than something we rely on, if needed, we should be
>> able to live without it too.
>> 
>> 
> have you considered René's proposal regarding the use of an I1-less
> BEX? The procedure of opportunistically responding with any DH group
> or a way of telling the preferred DH groups in a DHT packet could be
> options, right?

The overlays using HIP BONE are likely to need other common 
configuration information anyway (at least RELOAD instance does), so 
adding the preferred/default DH group(s) there should not be a problem. 
Also, the nodes that cached an R1 can notice that the cached version is 
from a wrong group (right?), and therefore not use the cached version 
but rather forward the I1 to the end host.

Cheers,
Ari

---

From: Tobias Heer <[email-masked]>
Date: Mon, 21 Jun 2010 10:04:01 +0200

Hi Ari, 

[...]
> The overlays using HIP BONE are likely to need other common configuration information anyway (at least RELOAD instance does), so adding the preferred/default DH group(s) there should not be a problem.
Okay.

> Also, the nodes that cached an R1 can notice that the cached version is from a wrong group (right?), and therefore not use the cached version but rather forward the I1 to the end host.
Yes, that makes sense. 

I'll change the text in RFC5201-bis if there are no further objections on the list.

Tobias