[secdir] Secdir review of draft-ietf-pim-sm-linklocal-06

[Brian Weis <[e-mail]>]

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: [phone]
Email: [e-mail]