RFC Errata
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