Subject: RFC 4322 errata

From: Alfred Hönes <[email-masked]>
Date: Mon, 20 Mar 2006 13:58:17 +0100 (MEZ)

Hello,
I'd like to send you a few comments on, and report a few textual
issues I found in, your recently published RFC 4322 (Opportunistic
Encryption for IKE).
I propose to post an Errata Note for RFC 4364 to resolve the issues
listed below under item (1) ... (8).

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

(1)  Section 1.1

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.  [...]

(2)  Section 1.2

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.

(3)  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.

(4)  Section 3.2.7

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.

(5)  Section 4.5

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

(6)  Section 9.3

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.  [...]

(7)  Section 11.2

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.
        [...]

(7)  Section 11.2, again

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.  [...]
                     ^^^^

(8)  Section 12.3

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.  [...]

(9)  General remark

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.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 20 Mar 2006 14:11:14 +0100 (MEZ)

Oops,
I just dectected a 'copy&paste' error in my last mail.
Of course, the ref. to RFC 4364 in the 4th text line
should have been made to RFC 4322 ! -- I apologize.
 
  Alfred.

--