Subject: RE: Cookie mechanism -- was -- Re: [Hipsec] Moving the base spec forward

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 13 Sep 2004 16:48:49 -0700

> -----Original Message-----
> From: Yogesh Prem Swami [mailto:[email-masked]] 
> Sent: Monday, September 13, 2004 12:20 PM
> To: ext Pekka Nikander
> Cc: [email-masked]
> Subject: Cookie mechanism -- was -- Re: [Hipsec] Moving the 
> base spec forward
> 
> 
> 3rd.
> 
> 
> ext Pekka Nikander wrote:
> 
> > 
> >> *  Optimize for most common case.
> > 
> > 
> > You can vary the cookie difficulty.  There is nothing wrong in
> > making K=0 by default.
> 
> 
> Right, but you still loose a Round Trip.

It is possible in theory (no one has implemented it yet) to
piggyback the TCP SYN and SYN/ACK on the 3rd and 4th packets,
respectively.
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 14 Sep 2004 14:05:16 +0300

> piggyback the TCP SYN and SYN/ACK on the 3rd and 4th packets,

Actually, if your implementation can defer tcb creation,
you can carry TCP SYN and SYN/ACK in the first and second
packets, respectively.  The third will then already contain
data traffic.  Hence, in the TCP/SCTP case the situation
can be arranged so that you don't loose any round trips.

For UDP, you have to wait 1 RTT.  You can piggyback data
on I2.

Implementation with the current PF_KEY is pretty tricky,
though.

--Pekka