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

[Ari Keranen <[e-mail]>]

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