I've read it again, and it seems fine. One minor issue, though.
Section 2 describes the WESP header format. It has the following:
HdrLen, 8 bits: Offset to the beginning of the Payload Data in
octets. The receiver MUST ensure that this field matches with
the header offset computed
All,
Below is an I-D that might be of interest to this group.
-Violeta
-Original Message-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org]
Sent: Thursday, July 02, 2009 10:40 AM
To: Cakulev, Violeta (Violeta)
Cc: a...@bridgewatersystems.com
Subject: New Version
Paul Hoffman writes:
Title : Heuristics for Detecting ESP-NULL packets
S, that was two months ago, and there has been no discussion.
Has anyone other than the document authors (and the WESP authors)
read the document? Does the WG find this to be useful?
Tero and Dan:
Hi Tero,
We have one working group draft dealing with new ESP-null implementations.
We have another draft dealing with unchanged ESP-null implementations. I
suggest we don't confuse everybody by adding a third category:
just-a-little-tiny-bit changed implementations. In other words, I think the
Hi Sean,
Sounds good. We will make the change in the next revision.
Thanks
Suresh
On 09-07-07 11:49 AM, Sean Turner wrote:
Suresh,
I think the last recommendation in 5.3.1 wrt the hashing algorithms in
PKIX certificates needs to be reworded: r/for PKIX certificates signed
with
Hi Raj
What Yaron suggested, was to create a new payload type, and mark that as
critical.
I don't like either Yaron's or Tero's suggestions, as both lead to a kind of
take it or leave it behavior. The initiator proposes doing childless, and
if the responder does not agree, the IKE SA breaks.
