Telechat Review of draft-ietf-mboned-ssmping-
|Requested revision||No specific revision (document currently at 09)|
|Team||Security Area Directorate (secdir)|
|I-D last updated||2011-08-01|
Secdir Telechat review of -??
by Vincent Roca
Tsvdir Last Call review of -?? by Scott O. Bradner
Hello, 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. After having read the security section and several parts of the document, I have noticed several small, easy to fix, incoherencies. More precisely: ** Section 9 says: "The worst case is if the host receiving the unicast Echo Replies also happens to be joined to the multicast group used." Yes in case of an ASM session, no in case of an SSM session (unless the server is also the SSM source, of course). This should be clarified. ** Section 9 says: "...responding to at most one Echo Request per second." It should be clarified that this is one response per second per client. BTW, I'm also wondering if there should not be a global rate limitation, in addition to the per-client rate limitation. ** Section 9 says: "The server SHOULD then only respond to Echo Request messages that have a valid Session ID associated with the source IP address of the Echo Request." How should the server behave if the Session ID is not valid? This is not clarified whereas this is a critical aspect. ** Section 9 says: Rather than saying "how spoofing can be prevented", I'd rather say "how spoofing can be mitigated" since spoofing is NOT prevented with this approach. Note also that an attacker that is on the path between a client and a server may eavesdrop the traffic, learn a valid Session ID, and if he can use spoofing, he can also continue generating Echo Requests until the Session ID validity period times out... A note may be added to clarify that this is by no means a definite security mechanism. ** Section 9, 2nd paragraph: It's clear that group management is critical with ASM, and that the multicast IP address range used for multicast ping SHOULD be disjoint from those used for data sessions. There is no clear recommendation though. I suggest to add some text here. ** Section 9 says: "The main concern is bandwidth." Is it really "the main concern"? I'm not sure. Disturbing an ASM data session with Echo Response traffic (when feasible) is a serious concern, since Echo Response traffic may be misinterpreted by the receivers. ** Section 3.3: When describing the format of the "Server Response, type 83", there should be a note that a Session ID option SHOULD be included, since this is the only way for a server to communicate this option. ** Section 4, "Client behaviour": must -> MUST in: "If the Server Response contained a Session ID, then it must also include that, with the exact same value, in the Echo Requests." ** Section 5, "Server Behaviour", says: "When the server receives an Echo Request message, it may first check that the group address and Session ID (if provided) are valid." This is a "MUST"!!! If the Session ID is used, the server has no choice but checking it during the first processing stages. ** Section 5: should -> SHOULD in: "The server should additionally include a Session ID." ** Section 3.2 "Defined options" I didn't find any information for the Session ID format. Is there any recommendation? Is a 16-bit or 32-bit field format recommended? Why? ** Section 5 says: "Note that the server may receive Echo Request messages with no prior Init message. This may happen when the server restarts or if a client sends an Echo Request with no prior Init message. The server may go ahead and respond if it is okay with the group used. If the group is not okay, the server sends back a Server Response." This "may go ahead and respond" is in total contradiction with the security recommendations. Using a Session ID is a "SHOULD", and it is allowed to ignore this recommendation only in rare circumstances. A few ping requests may fail if the server is restarted, sure, but this will only be a transitory problem, so it's not a big deal. I'm also wondering if the "sends back a Server Response" strategy is appropriate. With this "Response", an attacker that spoofs the IP address of a target has a way to oblige a server to send back a UDP packet to the target. It's questionable. Regards, Vincent