RE: Adding ECN to Transport and Recovery

["Lubashev, Igor" <[e-mail]>]

Thanks. So what you are saying is that a requirement for a on-a-side attacker to race cooked packets is what make this attack hard? I can buy this, especially since such an attacker could interfere with the initial version negotiation, too. The only thing that makes an attack on the congestion window nefarious vs an attack on version negotiation is that it leaves the user with an impression that the service is poor vs that the network is interfering with him connecting to the service.

-----Original Message-----
From: Magnus Westerlund [[e-mail]]
Received: Tuesday, 12 Jun 2018, 4:23AM
To: Lubashev, Igor [[e-mail]]; [e-mail] [[e-mail]]; [e-mail] [[e-mail]]
CC: [e-mail] [[e-mail]]; [e-mail] [[e-mail]]; [e-mail] [[e-mail]]
Subject: Re: Adding ECN to Transport and Recovery


Hi,

So, if the on-a-side attack manages to race its attack packet with CE set so that it arrives prior to the original packet with an ECT code-point it will affect the congestion window. The same way that if an attack can cause periodic network drop of packets for a QUIC connection the connection can't really distinguish this attack from a legit congestion indication signal.

So the PR's current security consideration addition says:

12.7.  Explicit Congestion Notification Attacks

   The ECN bits [RFC3168] are an unauthenticated signal from the
   network.  An on-path attacker may manipulate the value of the field.
   Thus, affecting the congestion avoidance behavior of the sender.  By
   clearing any CE marks the connection can help drive a bottle neck
   queue into a loss regime.  By setting the ECN field to CE marking it
   can drive down the senders congestion window thus resulting in
   reduced throughput.  The later could equally be accomplished by
   dropping packets for the connection.  Section 18 and 19 of [RFC3168]
   discusses the effects of undesired manipulation of the ECN field in
   more details.

   If a receiver would not have packet duplication detection and not
   discard any duplicates an off-path attacker that can receive copies
   of the connection's packets can manipulate the senders congestion
   avoidance state.  If packet duplicates are dropped, the off-path
   attacker will need to race the original packet to be successful in
   this attack.


If there is a proper on-path attack, then it can accomplish this already
to day by dropping packets, so ECN does not create a new vulnerability.
The requirement for an on-the-side attacker to successfully race its modified
packets make the attack harder to perform, the right situation must exist
where the normal route is longer than the route for the attacker, i.e.
tap -> attacker -> receiver. And the attacker must be able to tap the flow.
>From my perspective, that makes this an attack with limited applicability.

Mitigating the attack in either of the QUIC endpoints are also extremely
hard. How does a receiver or sender determine that the congestion signals
are manipulated? For an attacker that changes an ECT to ECN-CE I don't see
there being any reasonable detection mechanism. One would need to generate
parallel flow and statistically compare the behaviour of the flows to determine
that one flow was manipulated. But, such a flow is likely to be picked up by
an attacker as if I am attacking one I would tap the flows using a single
source or destination IP as flow template for the traffic that I as an
attacker are interested in.

For the case where an attacker removes the CE marks, that would be possible
to detect by sender side probes injecting CE marked packets, as discussed
in this issue: https://github.com/quicwg/base-drafts/issues/1426<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_1426&d=DwMD-g&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=fCJNH4_GrpJCEuL__VxRjfVtL0Cs4z66XI5BrJPbYi4&s=2_OCqkf4LQgo0ms4jC0p4xPnRUznLuTGsDfIhwcrcYY&e=>

My view is that the PR has the necessary text noting the issue and
referencing the far more extensive discussion in RFC 3168. We have an
issue to continue to discuss additional mitigation. Such mitigation should
be written up in a separate PR in my view.

Cheers

Magnus



Den 2018-06-11 kl. 14:18, skrev Lubashev, Igor:
I do not think I have seen this in the PR, so I am wondering what your recommendation is for defending against an on-a-side attacker, who sets CE bits on every EC(*) packet and races that packet to the destination? Should that be a part of this PR?

- Igor

-----Original Message-----
From: Magnus Westerlund [[e-mail]<mailto:[e-mail]>]
Received: Monday, 11 Jun 2018, 1:15PM
To: Jana Iyengar [[e-mail]<mailto:[e-mail]>]; Christian Huitema [[e-mail]<mailto:[e-mail]>]
CC: Brian Trammell (IETF) [[e-mail]<mailto:[e-mail]>]; Ian Swett [[e-mail]<mailto:[e-mail]>]; QUIC WG [[e-mail]<mailto:[e-mail]>]
Subject: Re: Adding ECN to Transport and Recovery


Hi,

I agree with Jana, as there are not a clear consensus lets take any further modifications of the ACK frames as a separate issue. The PR have from my perspective no open technical content issues. I will await to see if the editors or any of you have any editorial issues. But, otherwise I expect this PR to be merged quite soon.

I will now start working on a new section for a separate PR regarding the ECN black hole mitigation.

Cheers

Magnus

Den 2018-06-10 kl. 19:14, skrev Jana Iyengar:
Sounds like there's general agreement that modifying the varint to contain a flag bit will add unnecessary complexity.
Let's try to get the PR in as it is now, and if anyone really wants to go merge this and the ACK frame or rename things, let's paint that bikeshed separately.



On Sat, Jun 9, 2018 at 8:39 AM Christian Huitema <[e-mail]<mailto:[e-mail]>> wrote:


> On Jun 9, 2018, at 8:27 AM, Ian Swett <[e-mail]<mailto:[e-mail]>> wrote:
>
> QUIC is complex enough, I think we should just call them ACK and ACK_ECN.  A few implementations sending at least one ACK_ECN frame per connection will dispel any belief that ACK_ECN is optional.  A small amount of use will be a lot more valuable than clever naming.

Also, ECN is just one of the extensions that could be planned for ACK. Timestamps would be nice too, for those who want one-way-delay based congestion control.

-- Christian Huitema


--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>
----------------------------------------------------------------------


--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>
----------------------------------------------------------------------