RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (7)

RFC 4322, "Opportunistic Encryption using the Internet Key Exchange (IKE)", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area 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').

Status: Held for Document Update (2)

RFC 4322, "Opportunistic Encryption using the Internet Key Exchange (IKE)", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2450
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 1.2 says: 

The 2nd paragraph on page 3 says:

                     [...].  A future document [IPSECKEY] will describe
   a variation that complies with RFC 3445.  [...]

The reference  [IPSECKEY]  has been updated before publication of
RFC 4322 to point to RFC 4025 (cf. the first entry in Section 14.2,
on page 42).  Hence this wording in not appropriate and inconsistent.
The text should say:
                             vvvvvvvv                  vvv       v
|                    [...].  Another document [IPSECKEY] describes
   a variation that complies with RFC 3445.  [...]

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: 2453
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 3.2.7 says: 

The second paragraph of that section refers to [RFC1034]:

   The DNS query and answer that lead to the expiring connection state
   are also examined.  The DNS query may become stale.  (A negative,
   i.e., no such record, answer is valid for the period of time given by
   the MINIMUM field in an attached SOA record.  See [RFC1034] section
   4.3.4.)  [...]

This reference is not very appropriate, and hence misleading.
RFC 1034, and in particular section 4.3.4 of RFC 1034, has been
substantially clarified and updated by RFC 2308.
The Abstract of RFC 2308 says:
   "This document ... replaces [RFC1034 Section 4.3.4]."
(The precise rule for determining the 'negative caching TTL' is a
bit more complicated, taking the minimum of SOA.MINIMUM and SOA.TTL.)

Therefore, RFC 4322 should better refer to RFC 2308, in this place,
perhaps with a detailed hint pointing to section 5 of RFC 2308.

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').

Status: Rejected (1)

RFC 4322, "Opportunistic Encryption using the Internet Key Exchange (IKE)", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 125
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Rejected by: Sean Turner
Date Rejected: 2010-08-06

Section General says: 

It's a pity that RFC 4322, published a few days *after* the new IPsec
RFCs including the IKEv2 specification (RFC 4306), does not give a
perspective on Opportunistic Encryption in the context of IKEv2.

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').
--VERIFIER NOTES--
No action proposed.

Report New Errata



Advanced Search