Re: Tsvart last call review of draft-ietf-ice-rfc5245bis-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

See responses inline


Den 2018-02-02 kl. 12:12, skrev Christer Holmberg:

---


E. Section 7.2.5.2.2.  ICMP Error

      An ICE agent MAY support processing of ICMP errors for
connectivity
      checks.  If the agent supports processing of ICMP errors, and
if a
      Binging request generates an ICMP error, the agent SHOULD set
the
      state of the candidate pair to Failed.

I am a bit worried by this blanket statement on ICMP errors. I think
it
should
be clarified which ICMP message types that are relevant to consider
as
errors?
I assume Type 3 (Destination Unreachable) but maybe not all responde
codes as
Codes 4, 11,12 may be addressable in other ways, and likely Type 11
(Time
exceeded) with response code 0, response code 1 is not a clear
indication
of a
non working path.
This is from RFC 5245.

I don¹t think the ICE WG should go through all different codes and
combinations, and determine what should be considered an error, and
what
not.

If you can provide something (table, guidance etc), we are happy to
include it. Otherwise I¹d like to keep it as it is, and let
implementations deal with it, as at least I am not aware that this
would
Have caused issues in ICE deployments.
I think we there is a point to clarify that this applies to ICMP
messages indicating a non-usable path. So maybe it could be rewritten
to
something like this:

     An ICE agent MAY support processing of ICMP messaging indicating a
non-functioning path for connectivity
     checks. ICMP messages of type 3 (Destination Unreachable) are
indicators of a currently non-functioning path. However, the issue can
be
temporary as it can depend on routing transients, this for example
applies to codes 0, 1 and 5. Other messages that appear to indicate
non-functioning path such as Type=11 (Time Exceeded) with code=0 (Time
to
Live exceeded in Transit) are not clear indicator as the IP packets
potentially can reach the destination with a larger TTL value set at
transmission. Therefore, implementation needs to analyse the different
ICMP messages types and codes for which it considers the path as
non-functioning. If the agent supports processing of ICMP errors, and
if a
     Binging request generates an ICMP error, the agent SHOULD set the
     state of the candidate pair to Failed.


What also is not addressed in this is the risk of denial of service
attacks using spoofed ICMP messages to shutdown certain connectivity
checks. The security considerations lack any discussion of this issue.
If ICMP processing are retained, I think a recommendation about
validation is needed to avoid at least off path attackers from doing
these attacks easily. Unfortunately ICMP response will only include the
IP/UDP header, thus no data from the STUN messages which would allow
verification that the ICMP messages matches an actually sent check.

It may be simplest to recommend against reacting to ICMP errors from
both the perspective that it is a risk for denial of service attack, as
well as that it represents a risk terminating connectivity checks for a
transient issue. From my perspective I expect this to reduce the number
of sent connectivity checks very little
So, are you saying that an agent should simply ignore ICMP messages?
Yes, I think that may be the best. There are a bit to many corner cases
and significant attack surface that getting all the details right are
significant work for a relatively small reduction in sent connection
check messages.
I am not an expert, but aren’t you going to get ICMP unreachable every
time you try to contact a host candidate behind a NAT? Are you saying that
the agent should ignore it, as the connectivity test will anyway timeout
at some point?

To my understanding NATs and firewalls do not send ICMP unreachable because that would violates its role as a gateway rather than end-host, also it want to avoid giving away information about its internal side, and is a risk in creating a lot of load on the middlebox.


Also, note that RFC 5398 (STUN) says:

   "A STUN transaction over UDP is also considered failed if there has been
a
    hard ICMP error [RFC1122].”

I am a little worried that people would have to use ICE-specific STUN
stacks if they are required to ignore ICMP errors.

Couldn’t we simply use the existing text, and add a sentence about DoS
attacks?



OLD:

  An ICE agent MAY support processing of ICMP errors for connectivity
  checks.  If the agent supports processing of ICMP errors, and if a
  Binging request generates an ICMP error, the agent SHOULD set the
  state of the candidate pair to Failed.



NEW:

  An ICE agent MAY support processing of ICMP errors for connectivity
  checks. If the agent supports processing of ICMP errors, and if a
  Binging request generates an ICMP error, the agent SHOULD set the
  state of the candidate pair to Failed. Implementers need to be aware
that ICMP errors can be used as a method for denial of service attacks
when making a decision on how and if to process ICMP errors.

I think you need to at least make it clear that it is "hard ICMP errors". Which RFC 1122 defined as Type 3 with codes 2-4 for TCP. So, in that case one could just as well be explicit. I don't know if any of the later defined codes are defined as hard errors.

When it comes to the security consideration, I am actually quite worried by this. To spoof ICMP so that they arrive back at the client, you need to be able to send an ICMP packet back that matches the NAT's binding. That requires that you now the connectivity checks intended target address+port, and the NAT's source address+port. With that information you can generate an ICMP message that will arrive at the agent as long as the attacker can route a packet to the NATs address. And if you are in the local address domain to the agent, you can fake an ICMP error with only the information matching the peer agents candidate.

I think this issue do need security considerations text.

=======

Minor/Editorial Issues:

---

9. Section 15:

4.57566E+18 (note that
     an implementation would represent this as a 64-bit integer so as
not
     to lose precision).

Why the floating point representation? Priorities are integer numbers
and
thus
should be presented as such in this example.
This is from RFC 5245, and unfortunately I don¹t know.
Can you not just calculate the 64-bit integer and write it out?
So, you want me to write 4575660000000000000?
No, I thought the pair priority will not be 0 for the lower 32 bits and
that there actually are overflow in this deduction. My understanding is
that what should be written here is the calculation of:

pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

Where G and D are the priority values for $L_PRIV_1 and $R_PUB_1.

$L_PRIV_1 is L's host candidate, and stated to have a priorty of
2130706431

$R_PUB_1 is R's host candidate and stated to have a priorty of 2130706431

So G = 2130706431 and D=2130706431

pair priority then becomes 2^32*2130706431 + 2*2130706431 + 0 =
9151314442783293438

Thus, I think the next two pair priorities in the example also needs to
be fixed.

The first pair priority for R is the same value as for L, as G and D are
identical. But the next value will
be different. To my understanding L will be controlling, i.e. L's
candidate will be G

G=1694498815
D= 2130706431

Pair priority = 2^32*1694498815+2*2130706431 + 0 = 7277816997797167102
Please provide text for the section (or, at least the modified paragraphs)
:)

Fine, I can put in the numbers in the right place. But please check my calculations:

OLD:

   Agents L and R both pair up the candidates.  They both initially have
   two pairs.  However, agent L will prune the pair containing its
   server reflexive candidate, resulting in just one.  At agent L, this
   pair has a local candidate of $L_PRIV_1 and remote candidate of
   $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that
   an implementation would represent this as a 64-bit integer so as not
   to lose precision).  At agent R, there are two pairs.  The highest
   priority has a local candidate of $R_PUB_1 and remote candidate of
   $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a
   local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and
   priority 3.63891E+18.

NEW:

   Agents L and R both pair up the candidates.  They both initially have
   two pairs.  However, agent L will prune the pair containing its
   server reflexive candidate, resulting in just one.  At agent L, this
   pair has a local candidate of $L_PRIV_1 and remote candidate of
   $R_PUB_1, and has a candidate pair priority of 9151314442783293438.
   At agent R, there are two pairs.  The highest
   priority has a local candidate of $R_PUB_1 and remote candidate of
   $L_PRIV_1 and has a priority of 9151314442783293438, and the second has a
   local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and
   priority 7277816997797167102.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------


<<attachment: smime.p7s>>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]