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

Paul Hoffman <> Sun, 04 October 2020 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34DC63A083F for <>; Sun, 4 Oct 2020 08:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, MAY_BE_FORGED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eJ-g08u4NZku for <>; Sun, 4 Oct 2020 08:17:15 -0700 (PDT)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7146E3A0658 for <>; Sun, 4 Oct 2020 08:17:15 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 094FF9qh051524 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <>; Sun, 4 Oct 2020 08:15:10 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be []
From: "Paul Hoffman" <>
To: "IETF SAAG" <>
Date: Sun, 04 Oct 2020 08:17:13 -0700
X-Mailer: MailMate Trial (1.13.2r5673)
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
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 15:17:17 -0000

I like Christian's triage (minus the "men"). The "where are they 
relative to the path" differentiation is likely to be more 
understandable to people who are not security geeks than "what they can 
do with creative use of packets". Using a road analogy: a person running 
a tollbooth, a person who can watch the cars go by and tell his 
colleagues when to enter the stream in order to do damage, a person who 
cannot see the traffic or send in cars but can cause lightning storms 
and send fake news to the cars on the road.

--Paul Hoffman

On 3 Oct 2020, at 22:23, Christian Huitema wrote:

>> 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