RFC Errata
Found 7 records.
Status: Verified (7)
RFC 4322, "Opportunistic Encryption using the Internet Key Exchange (IKE)", December 2005
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 2455
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 9.3 says:
The first senrtence of Section 9.3, on page 34, says: Tunnels sometimes go down because the remote end crashes, disconnects, or has a network link break. [...] The 'line break' might occor at any place within the network, not just at the 'remote end'. Therefore, the text should better say: Tunnels sometimes go down because the remote end crashes, | disconnects, or a network link break occurs. [...]
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2456
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 11.2 says:
Within the details of step 5, the text on page 38, lacks of a
sub-step label.
The text,
(5J) DNS replies with public key of initiator.
Upon successfully authenticating the peer, the connection
instance makes a transition to authenticated OE peer on SG-B.
The format of the TXT record returned is described in
Section 5.2.
Responder replies with ID and authentication.
SG-B sends its ID along with authentication material, completing
the phase 1 negotiation.
(5L) IKE phase 2 negotiation.
[...]
should say:
(5J) DNS replies with public key of initiator.
Upon successfully authenticating the peer, the connection
instance makes a transition to authenticated OE peer on SG-B.
The format of the TXT record returned is described in
Section 5.2.
| (5K) Responder replies with ID and authentication.
SG-B sends its ID along with authentication material, completing
the phase 1 negotiation.
(5L) IKE phase 2 negotiation.
[...]
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2458
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 12.3 says:
The second paragraph of Section 12.3 (on page 41) says:
The design of ISAKMP/IKE, and its use of cookies, defend against many
kinds of denial of service. [...]
It should say:
v
| The design of ISAKMP/IKE, and its use of cookies, defends against
many kinds of denial of service. [...]
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2451
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 1.2 says:
The last paragraph of that section, on page 4, says:
[...]. The
mechanism described here, however, does provides an additional way to
distribute the authentication materials; it is a public key method
that does not require deployment of an X.509 based infrastructure.
It should say:
vvv
[...]. The
| mechanism described here, however, does provide an additional way to
distribute the authentication materials; it is a public key method
that does not require deployment of an X.509 based infrastructure.
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2457
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 11.2 says:
The final paragraph of Section 11.2, on page 39, says:
SG-A sends the datagram saved at step (5) through the newly
created tunnel to SG-B, where it gets decrypted and forwarded.
Bob receives it at (7) and replies at (8). SG-B already has a
| tunnel up with G1 and uses it. [...]
^^
"G1" is undefined; apparently, it should be "SG-A".
Hence, this snippit should say:
SG-A sends the datagram saved at step (5) through the newly
created tunnel to SG-B, where it gets decrypted and forwarded.
Bob receives it at (7) and replies at (8). SG-B already has a
| tunnel up with SG-A and uses it. [...]
^^^^
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2454
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 4.5 says:
The first paragraph of Section 4.5, on page 25, says: The implementation described (FreeS/WAN 1.98) neither uses DNSSEC directly to explicitly verify the authenticity of zone information, nor uses the NSEC records to provide authentication of the absence of a TXT or KEY record. [...] It should say: The implementation described (FreeS/WAN 1.98) neither uses DNSSEC directly to explicitly verify the authenticity of zone information, | nor does it use the NSEC records to provide authentication of the absence of a TXT or KEY record. [...] (or similar).
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
Errata ID: 2452
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Verifier Name: Sean Turner
Date Verified: 2010-08-06
Section 3.2.5 says:
Section 3.2.5
a) The second paragraph of Section 3.2.5, on page 16,
Exit from this state occurs with either a successfully created IPsec
SA or a failure of some kind. Successful SA creation results in a
transition to the key connection state.
should correctly name the state (cf. the Figure in Section 3.2, and
Section 3.2.6) by saying:
Exit from this state occurs with either a successfully created IPsec
SA or a failure of some kind. Successful SA creation results in a
| transition to the keyed connection state.
^^
b) The second paragraph on page 17 contains the sentence:
[...]. For an OE-
pessimistic connection, the initiator makes a transition to the deny
connection again with a low lifespan. [...]
Conformant to the terminology used in the remainder of the text
(cf. the definition in the 3rd paragraph of Section 3.2, on page 12),
it should say:
vvvvvvvv
| [...]. For an OE-paranoid
connection, the initiator makes a transition to the deny connection
again with a low lifespan. [...]
c) The final paragraph of the section, still on page 17, says:
The third failure occurs when there is signature failure while
authenticating the remote gateway. This can occur when there has
been a key roll-over, but DNS has not caught up. In this case again,
the initiator makes a transition to the clear-text or the deny
connection based upon the connection class. However, the lifespan
depends upon the remaining time to live in the DNS. [...]
It should say:
vvv
| The third failure occurs when there is a signature failure while
authenticating the remote gateway. This can occur when there has
been a key roll-over, but DNS has not caught up. In this case again,
the initiator makes a transition to the clear-text or the deny
| connection state based upon the connection class. However, the
lifespan depends upon the remaining time to live in the DNS. [...]
^^^^^^^
Rationale for the second change:
Transitions occur between *states* in the FSM. 'clear-text' and
'deny connection' are names given to two of these FSM states.
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').