Early Review of draft-ietf-pim-sm-linklocal-
review-ietf-pim-sm-linklocal-secdir-early-weis-2009-02-26-00

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