Telechat Review of draft-ietf-mboned-ssmping-
review-ietf-mboned-ssmping-secdir-telechat-roca-2011-08-01-00
| Request | Review of | draft-ietf-mboned-ssmping |
|---|---|---|
| Requested revision | No specific revision (document currently at 09) | |
| Type | Telechat Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2011-07-12 | |
| Requested | 2011-06-17 | |
| Authors | Stig Venaas | |
| Draft last updated | 2011-08-01 | |
| Completed reviews |
Secdir Telechat review of -??
by
Vincent Roca
Tsvdir Last Call review of -?? by Scott O. Bradner |
|
| Assignment | Reviewer | Vincent Roca |
| State | Completed | |
| Review |
review-ietf-mboned-ssmping-secdir-telechat-roca-2011-08-01
|
|
| Completed | 2011-08-01 |
review-ietf-mboned-ssmping-secdir-telechat-roca-2011-08-01-00
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