RFC Errata
Found 4 records.
Status: Verified (1)
RFC 4230, "RSVP Security Properties", December 2005
Source of RFC: nsis (tsv)
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
Status: Held for Document Update (3)
RFC 4230, "RSVP Security Properties", December 2005
Source of RFC: nsis (tsv)
Errata ID: 976
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Wes Eddy
Section 3.2 says:
The sending system needs to maintain the following attributes in such
a security association [1]:
[...]
o Latest sequence number (received with this key identifier)
It should say:
The sending system needs to maintain the following attributes in such
a security association [1]:
[...]
o Latest sequence number (sent with this key identifier)
Notes:
received --> sent
from pending
Errata ID: 977
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Wes Eddy
Section 3.4 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.
It should say:
[not submitted]
Notes:
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 ?
from pending
Errata ID: 2841
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marco Molteni
Date Reported: 2011-06-17
Held for Document Update by: Wes Eddy
Section 3.4 says:
In addition to host-based authentication with the INTEGRITY object inside the RSVP message, user-based authentication is available as introduced in [2].
It should say:
In addition to host-based authentication with the INTEGRITY object inside the RSVP message, user-based authentication is available as introduced in [7].
Notes:
This wrong cross-reference appears at least in the HTML version of RFC4230, at http://tools.ietf.org/html/rfc4230.
Reference [2] is "RSVP Extensions for Policy Control", RFC 2750, while it should be Reference [7] "Identity Representation for RSVP", RFC 3182.