[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AH/ESP edits
Folks,
Thank you for the help and careful review. Based on the feedback so
far, we've made the following changes to the AH and ESP documents. Our
apologies for any comments we missed (or misunderstood). Please let us
know your opinions about the pending items below by Friday the 13th
(6/13/97).
Thanks again,
Karen
Pending items
-------------
1. ESP: location of the IV in the payload section -- Should the IV be
specified as always at the beginning, default at the beginning of the
payload field with the option of algorithm-specific locations or
always algorithm-specific? (see email from Steve Kent on 6/3/97)
2. AH: Payload length -- Should this be AH header minus 2 32-bit words
or minus 3 words? In recent drafts, this field has been specified as
the AH header minus the fixed portion (This was 2 32-bit words and is
now 3 words). (see email from Steve Kent on 6/3/97).
ESP
---
1. In section 3.1, "ESP Header Location", IPv6 tunnel-mode diagram,
replaced "AH" with "ESP" in the note under the diagram.
2. In section 3.2.5, "Fragmentation", replaced "AH" with "ESP".
3. In section 2.2 "Sequence Number"... Corrected/clarified the text on
initialization to say, "The sender's counter and the receiver's
counter are initialized to 0 when an SA is established. The sequence
number, the sender's counter, and the receiver's counter must never
be allowed to cycle. Thus, they MUST be reset (by establishing a new
SA and thus a new key) prior to the transmission of the 2^32nd packet
on an SA.
4. In section 3.3.4, "Integrity Check Value Verification", DISCUSSION...
Changed the wording from "Now perform the ICV computation and compare
the result with the received value." to "Now perform the ICV
computation and compare the result with the saved value."
5. In section 2.4, "Padding (for Encryption)... Changed to specify a
default for the padding value (random data) with the algorithm
documents allowed to override this and specify a different padding
value if so desired. "As a default, the Padding bytes SHOULD be
initialized with random data and they are transmitted. The
transmitter can add 0-255 bytes of padding. Any encryption algorithm
used with ESP that requires a padding value other than the default
value MUST define its padding requirements in an RFC specifying how
the algorithm is used with ESP. The content of the Padding field
will thus be determined by the encryption algorithm and mode selected
and defined in the corresponding algorithm RFC."
6. In section 3.3.3, "Sequence Number Verification", 3rd paragraph...
Changed the wording from "The default window size is 32 ... A larger
window size MAY be established during SA negotation. If a larger
window size is negotiated it MUST be a multiple of 32. " to "The
default window size is 32 ... A larger window size MAY be chosen by
the receiver (and reported to the transmitter) during SA negotiation.
If a larger windowsize is chosen it MUST be a multiple of 32. "
7. In section 3.2.3.1, paragraph 1, line 6: "the the" --> "the".
8. In section 3.3.2, paragraph 1, line 5: deleted "Sequence Number and";
changed "fields" to "field".
9. In section 3.3.3, DISCUSSION, line 3: "packet" --> "the packet".
AH
--
1. In section 2.2, "Payload Length"... In the sentences, "A "null"
authentication algorithm may be used only for debugging purposes.
Its use would result in a "1" value for this field, as there would be
no corresponding Authentication Data field.", the value will be
adjusted to "0" or "1" depending on the decision on whether to
subtract 2 or 3 words from the AH header.
2. In section 2.2, "Payload Length"... We've added the text, "In the
"standard" case of a 96-bit authentication value plus the 3 32-bit
word fixed portion, this length field will be "tbd". (tbd depends on
the decision on whether to subtract 2 or 3 words from the AH header.)
3. In section 2.5, "Sequence Number"... Corrected/clarified the text on
initialization to say, "The sender's counter and the receiver's
counter are initialized to 0 when an SA is established. The sequence
number, the sender's counter, and the receiver's counter must never
be allowed to cycle. Thus, they MUST be reset (by establishing a new
SA and thus a new key) prior to the transmission of the 2^32nd packet
on an SA.
4. In section 3.2.3.2.1, "Authentication Data Padding"... Changed the
wording from "the IP protocol context (v4 or v6)" to "the IP protocol
version (v4 or v6)".
5. In section 3.2.3.2.1, "Authentication Data Padding"... Changed the
wording from "These bytes are included in the Authentication Data
calculation,..." to " These padding bytes are included in the
Authentication Data calculation,..."
6. In section 3.3.1, "Reassembly"... Changed the wording from "If a
packet offered to AH for processing appears to be an IP fragment,
e.g., the OFFSET field is non-zero..." to "If a packet offered to AH
for processing appears to be an IP fragment, i.e., the OFFSET field
is non-zero or the MORE FRAGMENTS flag is set...
7. In section 3.3.3, "Sequence Number Verification", 3rd paragraph...
Changed the wording from "The default window size is 32 ... A larger
window size MAY be established during SA negotation." to "The default
window size is 32 ... A larger window size MAY be chosen by the
receiver (and reported to the transmitter) during SA negotiation."
8. In section 3.3.4, "Integrity Check Value Verification", DISCUSSION...
Changed the wording from "Now perform the ICV computation and compare
the result with the received value." to "Now perform the ICV
computation and compare the result with the saved value.
9. In section 3.2.3.1.2, "ICV Computation for IPv6", ... Added
"Priority" and "Flow Label" to the list of fields zero'd prior to
performing ICV calculation. "Version" was left covered. "IPv4
Offset" was left uncovered.
Follow-Ups: