I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies mechanisms to authenticate the PIM-SM link local messages using ESP and AH. Since these messages are sent to a link-local multicast addresses (potentially to a group of receivers), the document describes the use of group keys shared between the PIM speakers on a particular LAN. The use of IPsec manual keying is specified as mandatory, with an option of automated group key management also discussed. For the most part, this document describes a use of IPsec that matches the IPsec Architecture (RFC 4301) and Multicast Extensions to the IPsec Architecture (RFC 5374). But I do have a few issues with choices made by the document, followed by some more routine comments. Issues ====== Section 9.3, third bullet. This bullet tacitly describes both DES and HMAC-MD5 as good to use, although neither are good choices these days. I recommend replacing the last two bullets with one that recommends the use of AES-CBC and HMAC-SHA1. Section 10.2.2. The second paragraph states that "the arrival of a PIM- SM link-local message" will trigger changes to the GSPD, and the last paragraph says that a PIM-SM message from an unknown peer would cause the router to query the group key management system in order to discover new PIM neighbors. Neither RFC 4301 or RFC 5374 advocate setting up IPsec state triggered from an unprotected interface because of the denial of service opportunity it gives attackers, and this document should not proscribe it either. I suggest removing the phrase from paragraph 2, and replacing paragraph three with wordage similar to the following: "A router SHOULD NOT dynamically detect new neighbors as the result of receiving an unauthenticated PIM-SM link- local message or an IPsec packet which fails an SAD lookup. An automated key management protocol SHOULD provide a means of notifying a router of new, legitimate neighbors." Section 11, second paragraph. The statement "various prohibitions in the IPsec RFCs concerning multisender multicast SAs" is not exactly correct. While RFC 4302 (AH) and RFC 4303 (ESP) say this situation is "not recommended" (because anti-replay cannot be used with a sequence number), RFC 4301 says "Multiple senders to a multicast group SHOULD use a single Security Association ...." (Section 4.6) due to the difficulty of authenticating a particular sender (i.e., one a single sender SA). Because this is a murky area, I suggest either removing the the prohibition verbage or removing the paragraph. Section 12. This section has too much discussion of anti-replay use with manual keys, in my opinion. As stated in the third paragraph it is not recommended to use a sequence number for anti-replay with manual keys, and this is in accordance with the IPsec RFCs. It should be left at that. Furthermore, the proposed use of counters and ESN values (list item b) does not match RFC 4303, which says "the sequence number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced". Starting counters over at zero after a reboot and then accepting any particular starting point in the sequence number space enables an attacker to replay any number of previously sent packets, which is unacceptable. Section 14. This section should state that when an ESN is used with a manually keyed SA that it MUST be saved over a reboot (as well as an indication of which sequence numbers have been used). Comments ======== Section 1, paragraph 4. This paragraph notes that securing unicast PIM- SM messages "can be achieved by the use of a normal unicast IPsec Security Association between the two communicants." That's correct, but the next sentence puzzles me: "Securing the user data exchanges is covered in RFC 3740." This RFC describes a multicast security architecture for large multicast groups, not unicast IPsec. Perhaps you meant RFC 4301? Section 1, paragraph 5. "This document recommends manual key management as mandatory to implement, i.e., that all implementations MUST support, ....". The use of "recommends" isn't quite right for a mandatory to implement feature. Perhaps "specifies" is better. Section 1.1, third paragraph. s/Permitted Access Database/Peer Authorization Database (PAD)/ Section 3. This section describes requirements on the use of Transport Mode and Tunnel Mode. These rules should be attributed to RFC 4301 (e.g., Begin the section "As stated in Section 4.1 of RFC 4301, ....."). Also it would be clearer in the second sentence to change "is a router/gateway" to "acting as a security gateway". Section 6. The "Encryption and authentication algorithms" requirement states that stream ciphers MUST NOT be configurable, because they "are not suitable for manual keys". However, they would be suitable if used with automated keying (which is an option in this document.) It would be better to make the restriction only in the case of manual keying. Also, the rest of this requirement (including by reference RFC 4835) is a little confusing, since RFC 4835 mandates the use of ciphers other than NULL but the PIM-SM link-local document states that support of confidentiality is optional. I suggest the following wording as a replacement for this section: "Encryption and authentication algorithm requirements described in RFC 4835 [RFC4835] apply when ESP and AH are used to protect PIM-SM. Implementations MUST support ESP-NULL, and if providing confidentiality MUST support the RFC 4838 required ESP transforms providing confidentiality. However, in any case implementations MUST NOT allow the user to choose a stream cipher or block mode cipher in counter mode for use with manuyal keys." Section 7.2. The paragraph referring to RSVP is probably intended to document a related automated group key management requirement, but is incongruous in this document. I suggest removing it. Section 8, paragraph following Figure 2. The sentence "Each node will look up the SA to be used based on the source address" is a little misleading. It should be "Each node will include the source address when searching the SAD for a match." (There may be other occurrences of this in the document too.) Section 8, last paragraph. This paragraph implies that "impersonation attacks" are not possible when automated keying is used. Actually, impersonation is possible whenever a symmetric group key is deployed regardless of the keying method (including when using the first method shown in Figure 2). I suggest deleting this sentence and leaving the topic for the Security Considerations section. Section 9. This section should say why it is important to periodically change keys, e.g. if there is a change of trusted personnel or to limit the risk of undetected key disclosure. When an implementation follows the algorithm requirements in RFC 4835 there, there should be no cryptographic reason to change keys. Section 9.1. I suggest changing the title to "Manual Rekeying Procedure". Section 9.3, last paragraph. This section considers the analysis in RFC 3562 to be relevant, but that analysis is really confined to the use of MD5 (not HMAC-MD5), which is not particularly relevant to algorithms used with IPsec since all are much stronger. I recommend removing the paragraph. Section 9.3, second bullet. This point isn't clearly stated elsewhere in the document. Perhaps Section 5 needs to make this statement. (But note that RFC 4301 already states that this combination is NOT RECOMMENDED.) Section 10.1.2. There are no IPsec traffic selectors defined to be as specific as "PIM message type". If PIM message types not mentioned here are sent to ALL_PIM_ROUTERS they will be encrypted as well. This section should be clear on this. Section 13. This section claims that RFC 4601 describes interface- specific SADs. It describes interface-specific SPDs, but not SADs. Brian -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew at cisco.com