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

[Tobias Heer <[e-mail]>]

 Hello Ari,

Am 09.06.2010 um 07:38 schrieb Ari Keranen:

> 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.
> 
> 
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



> Cheers,
> Ari




-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi