Subject: [Gen-art] Gen-ART Review of draft-ietf-mmusic-ice-17

From: Christian Vogt <[email-masked]>
Date: Thu, 16 Aug 2007 14:58:58 +0300

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.

(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.

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.

(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.

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.

Kind regards,
- Christian

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2007 17:36:45 -0400

Thanks for the comments. Responses inline.

>   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...

> 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.

> 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>

>   ...or plural in both cases.

fixed.

>   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-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2007 17:37:40 -0400

Fixed.

Thanks,
Jonathan R.

Guilherme Balena Versiani wrote:
> Just an addendum (below):
> 

> Section 7.1.1.1., 1st paragraph on page 40:
> 
>  "(...) This priority value will be computed identically to how
>  the priority for the local candidate of the pair was computed, except
>  that the type preference is set to the value for peer derived
>  candidate types."
> 
> Just a little conformance issue: "(...) for peer derived candidate
> types" would be "(...) for peer reflexive candidate types".
> 
> Regards,
> 
> Guilherme Balena Versiani.
> 
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>

---

From: Christian Vogt <[email-masked]>
Date: Tue, 21 Aug 2007 08:50:03 +0300

Jonathan,

two small comments.

> 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.  [...]

> this candidate isn't reachable from here. So you cannot pace the checks

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