Thanks for the comments. Responses inline.
Christian Vogt wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mmusic-ice-17.txt
Reviewer: Christian Vogt
Review Date: August 16, 2007
IETF LC End Date: August 13, 2007
Summary:
This document is of very good quality. It also has a very plausible
problem statement and an excellent summary of the ICE operation. I
support this document going forward in the publication process.
Comments:
A few comments still, but they are easy to fix:
(1) Section 2.6, 1st paragraph:
However, it is possible that packet
losses will cause a higher priority check to take longer to complete.
In that case, allowing ICE to run a little longer might produce
better results.
Just to avoid confusion: I would say "a packet loss" rather than
"packet losses". A reader might otherwise wonder why running "a
little longer might produce better results" if it would mean that
a high-packet-loss path gets eventually chosen.
OK. Of course there could be more than one packet loss, and it might
still be a better choice...
(2) Regarding the Security Considerations section:
Section 18.5.2, "STUN Amplification Attack", explains that ICE candidate
probes could be used for amplified flooding:
It is impossible to eliminate the amplification, but the volume can
be reduced through a variety of heuristics. [...]
A reader might at first glance wonder why the amplification could not be
avoided by requiring the initiator to send a separate request per
response. E.g., this is done in Mobile IPv6 route optimization where a
mobile host sends out two initialization messages that each prompt the
peer to send a single response message.
The problem is, that receipt of a response would assume connectivity.
The whole problem ICE is trying to resolve is that I don't know if I
have connectivity. It could be, the reason I got no response, is that
this candidate isn't reachable from here. So you cannot pace the checks
based on responses.
It might hence be valuable to note in section 18.5.2 that a "balancing"
of the number of request and response messages is not possible in the
case of ICE because the initiator does not know the number of responses
at the time it sends the request. In ICE, the number of responses
depends on both the initiator's and the responder's set of IP addresses.
Right.
I added the following paragprah at the end of that section:
<t>
Frequently, protocols that wish to avoid these kinds of attacks force
the initiator to wait for a response prior to sending the next
message. However, in the case of ICE, this is not possible. It is not
possible to differentiate the following two cases:
<list style="symbols">
<t>There was no response because the initiator is being used to launch
a DoS attack against an unsuspecting target that will not respond
</t>
<t>There was no response because the IP address and port is not
reachable by the initiator
</t>
</list>
In the second case, another check should be sent at the next
opportunity, while in the former case, no further checks should be
sent.
</t>
(3) Finally some editorial notes:
Section 2.1, 1st paragraph:
In all cases, such
a network interface appears to the agent as a local interface from
which ports (and thus a candidate) can be allocated.
s/ports (and thus a candidate)/a port (and thus a candidate)/
...or plural in both cases.
fixed.
Section 2.1, 2nd paragraph on page 11:
I assume "local interface Y" should be "local IP address Y" because
only the IP address is relevant for connectivity, not the interface.
And an interface may have multiple IP addresses, of course.
Yes, fixed.
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
