|
Hi,
I have reviewed the submitted updated document.
From my perspective, it resolves my issues. However, I think you
need to ensure that there are WG consensus on these changes.
Nit:
OLD:
IPv6 address from the local host can be
preferred.
NEW:
IPv6 addresses
from the local host can be preferred.
Cheers
Magnus
Den 2018-02-02 kl. 17:10, skrev
Christer Holmberg:
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
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 +46 10 7148287
Torshamnsgatan 23 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------
_______________________________________________
Ice mailing list
Ice@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/ice
--
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
----------------------------------------------------------------------
--
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
----------------------------------------------------------------------
|
