We've devised a new IPsec configuration mechanism, and we're performing a
controlled experiment comparing it to today's mechanisms. Accordingly, we're
looking for volunteers to participate in our study. (It's been submitted to
and approved by the university's Institutional Review Board (IRB).)
At 10:55 AM -0800 12/15/09, Paul Hoffman wrote:
>Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange will
>contain delete payloads for the paired SAs going in the other direction. There
>is one exception. If by chance both ends of a set of SAs independently decide
>to close the
At 2:21 PM -0800 12/16/09, Paul Hoffman wrote:
>Section 1.7 (Differences Between RFC 4306 and This Document) states:
>
> The protocol described in this document retains the same major
> version number (2) and minor version number (0) as was used in RFC
> 4306. That is, the version number is
At 2:29 PM -0800 12/16/09, Paul Hoffman wrote:
>Section 2.8.2 Simultaneous IKE SA Rekeying states:
>
> If only one peer detects a simultaneous rekey, redundant SAs
> are not created. In this case, when the peer that did not notice the
> simultaneous rekey gets the request to rekey the IKE SA
At 11:04 AM +0200 12/10/09, Yaron Sheffer wrote:
>This is to begin a 4 week working group last call for
>draft-ietf-ipsecme-ikev2bis-06. The target status for this document is
>Proposed Standard, obsoleting RFC 4306 and RFC 4718.
>
>Please send your comments to the ipsec list by Jan. 5, 2010, as
YES to both.
The WESP header provides a kind of rapid *deterministic* detection method
for ESP_NULL packet. The heuristics method is too complex and it calls for
more computing resource and computing time. I doubt the middle box whether
will support the heuristics method for ESP_NULL detection.
