Subject: [Hipsec] Packet reordering, certificates and base exchange

From: Teemu Koponen <[email-masked]>
Date: Thu, 16 Jun 2005 12:44:56 -0700

All,

The latest base-03-pre defines a control bit for both I2 and R2 to 
inform a peer to wait for shortly arriving certificate packets. 
However, I did not find any discussion how the peer should behave if a 
certificate packet arrives before I2/R2. Packet reordering is not 
anything rare in Internet, so it should be considered.

 From initiator's point of view, I think it just means that the 
responder's certificate packets should be cached for a short period of 
time. Someone else probably has a better understanding of the required 
time window, so I do not even try suggest any practical time. :-)

However, introducing caching in responder is not an option due to the 
fact that it should remain stateless until it receives I2. As the 
initiator cannot enforce the I2 to arrive before the certificates, 
without a significant delay between I2 and certificate packets, I 
wonder if it might make sense to alter the I2 to optionally contain a 
number of certificate parameters. Then, initiator could actually send 
multiple I2s, each containing a different certificate, or a single I2 
that possibly gets fragmented. If R2 gets the same enhancement, the 
certificate packet eventually becomes useless, I think.

Comments?

Teemu

--

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Jukka Ylitalo <[email-masked]>
Date: Fri, 17 Jun 2005 10:22:49 +0300

Hi,

> certificate packet eventually becomes useless, I think.
How about adding the solved puzzle to each certificate packet (also 
carried in the I2 packet)
going to the responder? The responder may establish a soft-state for the 
certificate packets
after validating the puzzle, and release the state, if I2 does not 
arrive in the assumed time frame.

-- Jukka

---

From: Teemu Koponen <[email-masked]>
Date: Sun, 19 Jun 2005 23:20:38 -0700

On Jun 17, 2005, at 0:22, Jukka Ylitalo wrote:

Jukka,

>> However, I did not find any discussion how the peer should behave if 
>> a certificate packet arrives before I2/R2. Packet reordering is not 
>> responder's certificate packets should be cached for a short period 
>> of time. Someone else probably has a better understanding of the 
>> required time window, so I do not even try suggest any practical 
>> time. :-)
>>
> going to the responder? The responder may establish a soft-state for 
> the certificate packets

Adding the solved puzzle to CER packets seems to me to be the smallest 
possible change to overcome the problem. However, at the moment I'm 
unable to see if a) adding the puzzle has any additional side-effects, 
b) is it enough alone.

Teemu

--