Subject: [Hipsec] HIP base exchange issues status

From: [email-masked] (Pekka Nikander)
Date: Mon Sep 8 08:45:01 2003

I thought it would be useful (at least for me) to briefly
list all the issues on the base exchange spec, and their
status.  It also appears that I reused the numbers 10-11,
and hence we have two of them.

Please do send your comments on the issues that have a
proposed solution.  Text to the open issues would be a
very nice surprise.

Summary:

   Closed:   1, 2, 6, 7, 8, (9), 10, 11
   Proposal: 4, 10a, 11a, 12, 14, 15
   Open:     3, 5, 13, 16

--Pekka Nikander

1. LSI

    Closed:  Use 1.0.0.0/8, with the low order 24 bits
    being from HIT, with some sort of collision detection.

2. Random SPI requirement

    Closed: Random SPIs are a SHOULD.

3. Unification of NES and REA packets

    Open.

4. Timestamps in R1

    Proposal: Add HMAC to R2, thereby closing the vulnerability.

5. Rules for extensions

    Open.

6. Cookie function

    Closed: Use SHA-1

7. Optional ESP payloads

    Closed: Removed from base specifiation, leaving
    space for adding them later.

8. BOS

    Closed: Kept, but made completely optional.

9. Packet processing

    Being closed:  Received initial text from Tom,
    adding some more of my own.

10. Fragmentation support

    Closed:  Fragmentation mandatory for IPv4, optional
    for IPv6.  See -07 for details.

11. Non-cryptographi HI

    Closed:  Removed.

10a. Which pseudo header format to use for IPv4 carried
      HIP packets, IPv6 or IPv4 format?

    Proposal: Use IPv4 format.

11a. Need to define the HMAC parameter, needed for
      mobility

    Proposal: HMAC being added.

12. It looks like R2 is too weak.  It should include
     something derived from KEYMAT, I think.  Maybe
     a HMAC payload?

    This is basically the same as isssue #4, in a
    different disguise.

    Proposal: Add HMAC to R2, thereby closing the vulnerability.

13. Define how to send multiple I1s to multiple IP
     addresses in parallel, and rate limitations.

    Open.

14. Possible weakness in receiving I2s in E3 state,
     as discussed in a previous mail.

    Proposal:  Add a new substate of E3 where the
    the host has a new KEYMAT ready to be taken into
    use when a new R2 is received.

15. Handling anonymous HITs in received R1 and I2.

    Proposal: Still check the HIT vs HI relationship
    even if the HIT is anonymous.

16. Details for handling of LSIs.

    Open.

---

From: [email-masked] (Pekka Nikander)
Date: Wed Sep 24 10:03:01 2003

Issue 3 has now a proposal on the NES side.  I think
that I will be able to work out the REA side.

I will next try to produce a proposal for issue 5.

I think that we can even let the spec pass without
specific rules for 13 or 16, leaving them for future
work.  (Opinions?)

Summary:

    Closed:   1, 2, 6, 7, 8, (9), 10, 11
    Proposal: 3, 4, 10a, 11a, 12, 14, 15
    Open:     5, 13, 16

To remind what was what:

5. Rules for extensions

--Pekka Nikander

---

From: [email-masked] (Julien Laganier)
Date: Wed Sep 24 16:17:00 2003

>      addresses in parallel, and rate limitations.

Hi Pekka,

Concerning the use of multiple addresses in parallel, I would like to know 
what do you guys think of the following paragraph:

       <t>For the sake of minimizing the session establishment latency, an
        implementation MAY send the same I1 to more than one of the 
	Responder's  addresses. Note that, however, upon timeout, such an 
	implementation MUST refrain from sending the same I1 packet to 
	multiple addresses, in order to avoid congestion of the network.</t>

        <t>As the Responder is not guaranteed to distinguish the
        duplicate I1's he receives at several of its addresses (because it
        avoids to store states when it answers back an R1), the Initiator
        may receive several duplicate R1's.</t>

        <t>The Initiator SHOULD then select the destination address
        using the source address of the first received R1 as a source address 
	for the next I2, and discards subsequent R1's. This strategy seems
	to be quite good in terms of RTT.</t>

Thanks,

--julien

---

From: [email-masked] (Pekka Nikander)
Date: Thu Sep 25 04:09:00 2003

Julien,

Thanks a lot!  I added a limitation that the host MUST NOT
send packets to more than three addresses in parallel.
That blocks the potential DoS attack of someone luring
a host to send I1s into 1000 addresses in parallel.
Other than that, I adopted the text as such.

--Pekka Nikander