IETF Logo Mail Archive

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

Christian Huitema <huitema@huitema.net> Wed, 02 September 2020 17:01 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C400A3A0BA7 for <saag@ietfa.amsl.com>; Wed, 2 Sep 2020 10:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q44zoeBFJ8dp for <saag@ietfa.amsl.com>; Wed, 2 Sep 2020 10:01:46 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20FFD3A0BAA for <saag@ietf.org>; Wed, 2 Sep 2020 10:01:40 -0700 (PDT)
Received: from xse350.mail2web.com ([66.113.197.96] helo=xse.mail2web.com) by mx165.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kDW8K-000Zst-Ox for saag@ietf.org; Wed, 02 Sep 2020 19:01:34 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4BhVZK3YYjz1dfL for <saag@ietf.org>; Wed, 2 Sep 2020 10:00:57 -0700 (PDT)
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kDW81-00065O-CE for saag@ietf.org; Wed, 02 Sep 2020 10:00:57 -0700
Received: (qmail 2085 invoked from network); 2 Sep 2020 17:00:57 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.38.240]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <mcr+ietf@sandelman.ca>; 2 Sep 2020 17:00:55 -0000
Content-Type: multipart/alternative; boundary="Apple-Mail-95343884-0636-4C2A-B98E-0D9E495A2732"
Content-Transfer-Encoding: 7bit
From: Christian Huitema <huitema@huitema.net>
Mime-Version: 1.0 (1.0)
Date: Wed, 02 Sep 2020 10:00:54 -0700
Message-Id: <B321AC1D-6DFF-49D4-A543-7B1F7C1B70DD@huitema.net>
References: <CABcZeBNWf=8TU_tJK5rKyh_Veaa5L0jhV9qkvL7M-k-BaNYoRA@mail.gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, IETF SAAG <saag@ietf.org>
In-Reply-To: <CABcZeBNWf=8TU_tJK5rKyh_Veaa5L0jhV9qkvL7M-k-BaNYoRA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: iPhone Mail (17G80)
X-Originating-IP: 66.113.197.96
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0VKALJWqpbz84ezJUOplsTqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59ftWpfT9b1D017sZwmLHDSvlU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/WSlmRJUKMrJ+ahcq82ahPryme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilZpnfSx1WjM8 Y221ho/pD3/Zen/OGK5W227fFu2y/4R9gMjXCCC0q8HqTe9TGmY4VZes/bRh/Q0PQgsIJofD2Djv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNliqbq1iQQhopQxqA dW22RV24VMfHLR4QGE9WzFLImqe1VBqf27VeHOkXe82afzWlDIsVvw36ToN4By3mNqM1QxGhHHAS JNUmoOHSoqgqxfHmWfZIwxxhwvMcWh0MGcvUtQgQue0IJugzONTiljfbavm81vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/tBFOB8_BA3ho7ZX92RXh4gYOn3o>
Subject: Re: [saag] can an on-path attacker drop traffic?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2020 17:01:48 -0000

The "on path" and "limited on path" can both read and inject traffic, but only on path attackers can suppress traffic.

An example of limited on path attackers are state level attackers who can observe traffic at a variety of points, bring it to a monitoring  facility, and inject traffic from there to interfere with targeted communications. TCP RST injection can easily work that way.

-- Christian Huitema 

> On Sep 2, 2020, at 9:45 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> QUIC ended up with a different taxonomy:
> On-path
> Off-path
> Limited on-path (cannot delete)
> 
> -Ekr
> 
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-29#section-21.12.3.1
> 
> 
>> On Wed, Sep 2, 2020 at 9:28 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>> 
>> I think most of us agree that an "on-path" attacker can read traffic.
>> They can problem inject traffic, and maybe even inject it in such a way that
>> it beats the real traffic.
>> 
>> I think that most of us can agree that an off-path attacker can not read
>> traffic.
>> 
>> So for instance, and on-path attacker can see the TCP SYN seq no or a DNS
>> query ID, and therefore answer correctly.
>> And off-path attacker has to depend upon implementation flaws to guess those
>> values. (Which at one point were very common)
>> 
>> A read-only on-path attacker that can read can be implemented with a MIRROR/SPAN port.
>> Or as we learnt a few years ago with creative bending of fiber.
>> 
>> A firewall or router is a potential on-path attacker, but it can also drop packets.
>> What do we call this?
>> This was historically called a MITM, and it implied all the attributes of
>> on-path.  But it is unclear to me if MITM > on-path, or MITM == on-path.
>> 
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>> 
>> 
>> 
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag

v2.23.0 | Report a Bug | By Email