Re: [Tsv-art] [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16

[Christer Holmberg <[e-mail]>]

Hi,

The text looks good to me.

I will add it, and submit a new version of the draft, so that we can move
forward.

IF someone has issues with the text, we can always fix it as part of
upcoming IESG review fixes.

Regards,

Christer

From:  Magnus Westerlund <[e-mail]>
Date:  Friday 2 February 2018 at 18:04
To:  Christer Holmberg <[e-mail]>, "[e-mail]"
<[e-mail]>
Cc:  "[e-mail]"
<[e-mail]>, IETF Discussion <[e-mail]>,
"[e-mail]" <[e-mail]>
Subject:  Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16

    
 

Hi,
 

On Christer's request I have written a text proposal for a security
consideration addition regarding the ICMP message. From my perspective, WG
input is needed into this issue!
 
 

New paragraph:
 
 


    Spoofed ICMP Hard Errors (Type 3, codes 2-4) can also be used to
    create false invalid results. If an ICE agent implements a response
    to these ICMP errors, and the attacker is capable of generating an
    ICMP message that is delivered to the agent sending the connectivity
    check. The validation of the ICMP error message by the agent is its
    only defence. For Type 3 code=4 the outer IP header provides no
    validation, unless the connectivity check was sent with DF=0.
    For code 2 or 3, which are originated by the host, the
    address is expected to be any of the remote agents host, reflexive, or
relay 
    candidates IP addresses. The ICMP message include the IP header and UDP
    header of the message triggering the error. These fields also needs to
    be validated. The IP destination and UDP destination port needs to match
    either the targeted candidate address and port, or the candidates base
    address. The source IP address and port can be any candidate for the
same 
    base address of the agent sending the connectivity check. Thus any
attacker 
    having access to the exchange of the candidates will have the necessary
    information. Thus the validation is a weak defence, and the sending of
    spoofed ICMP attacks is possible also for off-path attackers from a node
    in a network without source address validation.
 
 Intended to be added in Section 19.1  between two existing paragraphs as
indicated below.
 
 .. exchange signaling is secured, the attacker will not have the
    password and its response will be discarded.
 
 [The new paragraph]
 
 Forcing the fake valid result works in a similar way.  The agent ...
 


 
 

I hope this helps making it clear how relatively easy this attack can be
performed, and why I think it is actually safer to ignore any ICMP errors
for the connectivity checks.
 
 


 
 


 
 
 
Den 2018-02-02 kl. 15:28, skrev Magnus Westerlund:
 
 
> 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  [phone]
>  Torshamnsgatan 23           | Mobile [phone]
>  SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>  
>  
>  
>   
>  
> _______________________________________________
> Ice mailing list
> [e-mail]://www.ietf.org/mailman/listinfo/ice
>  
 
 
-- 

Magnus Westerlund 

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------