Re: [saag] can an on-path attacker drop traffic?

Christian Huitema <> Sun, 04 October 2020 05:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C55033A105E for <>; Sat, 3 Oct 2020 22:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yW9rqiNDN3_P for <>; Sat, 3 Oct 2020 22:23:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2234D3A105C for <>; Sat, 3 Oct 2020 22:23:33 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kOwUZ-0007pF-W8 for; Sun, 04 Oct 2020 07:23:31 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4C3sZf4FT7ztB3 for <>; Sat, 3 Oct 2020 22:23:22 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kOwUU-0003Jh-Fh for; Sat, 03 Oct 2020 22:23:22 -0700
Received: (qmail 15683 invoked from network); 4 Oct 2020 05:23:21 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 4 Oct 2020 05:23:21 -0000
Content-Type: multipart/alternative; boundary=Apple-Mail-AF012C8D-8EDC-4CFB-BC9D-F396C3A61113
Content-Transfer-Encoding: 7bit
From: Christian Huitema <>
Mime-Version: 1.0 (1.0)
Date: Sat, 3 Oct 2020 22:23:20 -0700
Message-Id: <>
References: <>
Cc: Michael Richardson <>, Fernando Gont <>, IETF SAAG <>
In-Reply-To: <>
To: Eric Rescorla <>
X-Mailer: iPhone Mail (17H35)
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.71)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVMpUGqoktPdof do6VQqSoRETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59ftsra6SECpO06iBsnkTuhZiU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5hmwN8D4LrepG7AX8WNwY8Mm/JD3cPBOX47Hg3FEpDo46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAmxx/Wk8McinP JEkgAVrOMpZe3hRpsu7wNFYkklzOSk+gn8xjOPPpotNGdiYmcA8z3gPBb9iGpTEjWGgNXUgraFIv UwPy3x0FYtCNEb10sHyQCLHEvD1OqP6bgZ4L66GcgBg66gs5OuzYxJgw5atIxeNDvjI/CYe5WPy0 +t1RP0azSDOyu53XgzieW2z5dggn85xMPnetLBJMh51NiRRoHIBmdjuhXtou9fyHZ5xUc1l1miK7 x42VjdzChZMe6O/Did+/hGXTmfhE+Dx2/NyzMXogeTaqPadUMySWqNjMcOK/vOnCUbNPgcPcQwzM gKHyQxUo+ql2ySTkvEFH/23XMww2BnTTFGX5/yI4Ky+1ZJcbGqc5H4PEZHeoI/d6LWFf332z7LMw LGdoi9FMQ5j9dQUvMi1YKAun15JQSJLyCT5k+MTObVKxHy/dols381l9r9ft9daDonlwd6LnuX+J u10=
Archived-At: <>
Subject: Re: [saag] can an on-path attacker drop traffic?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Oct 2020 05:23:36 -0000

> On Oct 3, 2020, at 8:00 PM, Eric Rescorla <> wrote:
>> The QUIC "on-path" attacker seems to be a Dolev-Yao attacker.
>> The "off-path" attacker seems to have the ability to observe
>> packets, which I normally would not think an off-path attacker would have.
>> So this definition is very surprising to me.
> I agree it's not ideal. QUIC has been pubreq-ed, so you could raise it in IETF-LC.

I think of it as man-in-the-middle, man-on-the-side and man-in-the-rough. For me, the man in the middle is what EKR refers to as the Dolev-Yao attacker; best hope there is to detect the attack and reduce it to a denial of service.

The man on the side is capable of reading the traffic and injecting messages; it cannot easily delete messages,  but it can win races and get his own fakery delivered before the genuine packets -- TCP RST is an example of such attacks. Various national organizations have that capability. It is much easier for them to implement than a full MITM. I think that with effort we can defeat this class of attackers.

The man in the rough does not see the traffic but can make guesses. DDOS attacks, port scanning, observing or gaming DNS caches fall in that category. Botnets sometimes resort to these attacks.

And yes, in 2020 we probably need names that don't carry "man-in-foo" imagery. But English is not my mother tongue...

-- Christian Huitema