Subject: RFC 4230 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Wed, 16 May 2007 20:02:12 +0200 (MESZ)

Hello,
quite a while ago, I had studied RFC 4230 (RSVP Security Properties)
authored by you, but I did not find the time to submit my comments
to you.  The recent publication of documents referencing your RFC
has pushed me back to resume working on my marginal notes.

Hereby, I would like to submit a few comments, pointing out the
issues I found with the RFC text, and supplying material to make
notice of for eventual future/derived work, and/or for an appropriate
RFC Errata Note.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  Section 3.1 -- word omission

On mid-page 7, Section 3.1 of RFC 4230 says:

   o  Keyed Message Digest:

       The Keyed Message Digest is a security mechanism built into RSVP
|      that used to provide integrity protection of a signaling message
       (including its sequence number).  [...]

It should say:

   o  Keyed Message Digest:

       The Keyed Message Digest is a security mechanism built into RSVP
|      that is used to provide integrity protection of a signaling
       message (including its sequence number).  Prior

(2)  Section 3.2  -- mis-specification

On top of page 8, Section 3.2 says:

       vvvvvvv
   The sending system needs to maintain the following attributes in such
   a security association [1]:

      [...]

|     o  Latest sequence number (received with this key identifier)
                                 ^^^^^^^^

I strongly suspect that this is perhaps a copy&paste error from
subsequent lines dealing with the receiving system, and that the
RFC should say, instead ot the last line quoted above:

|     o  Latest sequence number (sent with this key identifier)
                                 ^^^^

(3)  Section 3.4 -- mismatch between text and figure

The RFC text at the bottom of page 9 says:

        [...].  The RSVP INTEGRITY object (outer object) covers the
   entire RSVP message, whereas the POLICY_DATA INTEGRITY object only
   covers objects within the POLICY_DATA element.

Nevertheless, the subsequent Figure 1 (on top of page 10)
does *not* depict this security relevant object at all.

Has there something been fost from Figure 1 ?

(4)  Section 3.4 -- word omissions

In the first paragraph on page 11, Section 3.4 says:

                                             [...].  If user identity
|        confidentiality is provided, then the policy locator has to be
         encrypted with the public key of the recipient.  How to obtain
         this public key is not described in the document.  This detail
         may be specified in a concrete architecture in which RSVP is
         used.

It should say:
                           vvvvvvv
                                             [...].  If user identity
|        confidentiality is to be provided, then the policy locator has
         to be encrypted with the public key of the recipient.  How to
         obtain this public key is not described in the document.  This
         detail may be specified in a concrete architecture in which
         RSVP is used.

Rationale: Better balance the two parts of the tagged sentence!

(5)  Section 4.3 -- word omission

Within Section 4.3, near the bottom of page 27, the first paragraph
under the headline
    (6) Performance
says:
                                                             v
|                                       [...].  Otherwise, it difficult
       to say which identifier is used to index the security
       association.

It should say:
                                                             vvv
|                                       [...].  Otherwise, it is
       difficult to say which identifier is used to index the security
       association.

(6)  Section 5.4 -- spurious blank line

On top of page 36, the text in the last bullet, (3), of Section 5.4
contains a spurious blank line, perhaps a page reformating artifact.
The RFC says:

   (3) It is assumed that SPIs do not change during the lifetime of the
       established QoS reservation.  If a new IPsec SA is created, then
|
       a new SPI is allocated for the security association.  [...]

It should say:

   (3) It is assumed that SPIs do not change during the lifetime of the
       established QoS reservation.  If a new IPsec SA is created, then
       a new SPI is allocated for the security association.  [...]

(7)  Section 5.6 -- a typo and a word omission

Within Section 5.6, the second paragraph on page 37 says:

                              v
|  If an RSVP message can taket more than one possible path, then the
   IPsec engine will experience difficulties protecting the message.
   Even if the RSVP daemon installs a traffic selector with the
   destination IP address, still, no distinguishing element allows
   selection of the correct security association for one of the possible
|  RSVP nodes along the path.  Even if it possible to apply IPsec
   protection (in tunnel mode) for RSVP signaling messages by
   incorporating some additional information, there is still the
   possibility that the tunneled messages do not recognize a path change
   in a non-RSVP router.  [...]

It should say:

|  If an RSVP message can take more than one possible path, then the
   IPsec engine will experience difficulties protecting the message.
   Even if the RSVP daemon installs a traffic selector with the
   destination IP address, still, no distinguishing element allows
   selection of the correct security association for one of the possible
|  RSVP nodes along the path.  Even if it is possible to apply IPsec
   protection (in tunnel mode) for RSVP signaling messages by
   incorporating some additional information, there is still the
   possibility that the tunneled messages do not recognize a path change
   in a non-RSVP router.  [...]

(8)  Section 5.7 -- spurious blank line

Similar as noted in item (6) above, there is a spurious blank line
in the first paragraph of Section 5.7.
On top of page 38, the RFC says:

   mechanism, but authentication might, in many cases, be insufficient
   for authorization.  The communication procedures defined for policy
|
   objects [42] can be improved to support the more efficient per-
   channel financial settlement model by avoiding policy handling
   between inter-domain networks at a signaling message granularity.
   [...]

It should say:

   mechanism, but authentication might, in many cases, be insufficient
   for authorization.  The communication procedures defined for policy
   objects [42] can be improved to support the more efficient per-
   channel financial settlement model by avoiding policy handling
   between inter-domain networks at a signaling message granularity.
   [...]

(9)  Section 9.2 -- typo/punctuation

Within Section 9.2, the first entry on top of page 42 says:

   [21]  Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
|        strengthened version of RIPEMD in Fast Software Encryption",
         LNCS vol. 1039, pp. 71-82, 1996.

It should say:

   [21]  Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD-160: A
|        strengthened version of RIPEMD", in: Fast Software Encryption,
         LNCS vol. 1039, pp. 71-82, 1996.

Please comment and decide how to proceed.
If you want (some of) these issues be documented,
preferrably you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.

Kind 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]                     |
+------------------------+--------------------------------------------+