RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 4230, "RSVP Security Properties", December 2005

Source of RFC: nsis (tsv)
See Also: RFC 4230 w/ inline errata

Errata ID: 975
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Verifier Name: RFC Editor
Date Verified: 2007-11-02

 

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

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!


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.


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


Section 5.6 -- a typo and a word omission

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


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


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.

It should say:

[see above]

Notes:

from pending

Report New Errata



Advanced Search