Jonathan,
two small comments.
>> (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...
Sure. I was thinking that the text in the draft sounds a bit like /persistent/
packet loss. That was my impression. Maybe you just reformulate it to this:
[...] However, it is possible that a higher-
priority check takes longer to complete due to packet loss. [...]
>> 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.
What I was thinking of was not that the initiator should wait for request n+1
until it has received response n. Rather, the initiator could be required to
send N separate requests if it has N candidates, i.e., one request per
candidate. That would preclude amplification if and only if we have (at most)
one response per candidate.
But in the case of ICE, we typically have more than one response per candidate
given that there is one response per local/remote-candidate pair. So sending a
separate request for each candidate does not mitigate the amplification threat.
- Christian
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
