From nobody Wed Sep 2 09:27:59 2020 Return-Path: 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 301DE3A1296 for ; Wed, 2 Sep 2020 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J07t2scugBkx for ; Wed, 2 Sep 2020 09:27:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB843A128E for ; Wed, 2 Sep 2020 09:27:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id ED745389A8 for ; Wed, 2 Sep 2020 12:06:49 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4UP_toHWMKoH for ; Wed, 2 Sep 2020 12:06:48 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 84EED389A7 for ; Wed, 2 Sep 2020 12:06:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DA5281FB for ; Wed, 2 Sep 2020 12:27:52 -0400 (EDT) From: Michael Richardson To: saag@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 16:27:57 -0000 --=-=-= Content-Type: text/plain 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 , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEyBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9PyAgACgkQgItw+93Q 3WU1bQf44HKflqwh73Tzc2itTPYpnSU2n1R+9xZiWF+mtI6/223Q1Uc/nfEzb6e/ PXnqIJ8QVhg/1iw2yv62sYmDqPmXkndKza+TjVYvWSCVP3dunQ2h1Zxh660E3+9/ jkCThJSkmtEQBdF1aSxDbu7PdAofl6xk/aypo9C6Afx7saWMcMEJ5osHx1YpdsZH iNudIHi5xM02M4Sl7iB1cESq9kEVKogrktgaVxnbYGW3OiwaEgbmO22gbLVB4pQY LKE9oCfyU+Xw/y0PE9uphQQwBqDKTMcfgiL5ygbYZeSHx8jQsNM89K73ub0YZF+z s5pRdhpgk/3E70hRGXd0UNOR3u59 =lVXT -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 2 09:45:25 2020 Return-Path: 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 6CBB33A0E07 for ; Wed, 2 Sep 2020 09:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 vyhNPnzV0JjL for ; Wed, 2 Sep 2020 09:45:22 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C101A3A0529 for ; Wed, 2 Sep 2020 09:45:21 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id s205so6733948lja.7 for ; Wed, 02 Sep 2020 09:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vaoB9z7s2mekF3rpSVVt3sCIv4ek4XpJTDHOb6LfhWI=; b=EHMxxqYJAMgo5qPEyvcHwkE7rPkgQpBCFYYyH18rO+Bc7pI2BWFbZLVIlLrWIInOAA Sk6tNXXkl8nPru086Ua1tpY7Ahhb9WBzuXqXzjMbdqTXOIwlyYn5Zj6/1Jw+iVukxRpq otmvZ1/VEOi1FoKzcNnTfZXw1IgVyYtFQ5DDo0yZ/K8OIn9GIQaNLLgXO1S2behOOWy+ AfuUclT+nnwSsJarcytKHwEgntP3rc8evO0hMHVRc6GPf++xYQYj6sf6aLfSyMW9UnGz WqYz/y0hNlXBvFAQCQYXoEpCQSSYsKUDCMoQ88HwE4AlKM/2EE2zCH0RkVOYm7CIbRlt 586g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vaoB9z7s2mekF3rpSVVt3sCIv4ek4XpJTDHOb6LfhWI=; b=MDvPxAcLuCmMETMEX8QnEeE63yg6OIrhxaRjIBIpPYa/u1JEgml4TgaUwU3MrWaD3L WWuNHGJhlAfd8OMxFIbysIB22qbysq1gNvXCcTt0mhNZm7RIijOu4Xz6OQk23owOsx5j TKMl/PWW40JeChwkJgprA2c4EbGEr8toh6CkP6DXbOaHypIVfjq7vv8GIhCKZNGNiOlH PWOs5Z8wf8dfz989we9iMCtWUSqrqNZTZrYG7WGm8rvHlvlg8+FSmbdddUJg5mT65WP6 V8vqBmBgsjMkWsSbEgqIB+yV2CMYZemeEsJPwNydqMsItZwa5tY0EqB8qCs1pb8D7py2 BtVA== X-Gm-Message-State: AOAM533g7x4tuqIIU3xbe229yfpaRJIYnPheEQFt0sv1VOIyvdbzvNZM ibgxWSIp05SPEUiM3l08ynmxgtg2D/ag+HhdeSYJvA== X-Google-Smtp-Source: ABdhPJxmM1aKT2/i1tUMQuOnYZhKWH3naprHlA3/vaZJRxYX3IdvsWP4g3fF8oNr8zaIaMBZknoUZOvN3avJrtr8HCU= X-Received: by 2002:a2e:2241:: with SMTP id i62mr2502238lji.265.1599065119843; Wed, 02 Sep 2020 09:45:19 -0700 (PDT) MIME-Version: 1.0 References: <4645.1599064072@localhost> In-Reply-To: <4645.1599064072@localhost> From: Eric Rescorla Date: Wed, 2 Sep 2020 09:44:43 -0700 Message-ID: To: Michael Richardson Cc: IETF SAAG Content-Type: multipart/alternative; boundary="00000000000070ff2505ae575c2c" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 16:45:24 -0000 --00000000000070ff2505ae575c2c Content-Type: text/plain; charset="UTF-8" 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 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 , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --00000000000070ff2505ae575c2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
QUIC ended up with a different taxonomy:
On= -path
Off-path
Limited on-path (cannot delete)

-Ekr




On Wed, Sep 2, 2020 at 9:28 AM M= ichael Richardson <mcr+ietf@s= andelman.ca> wrote:

I think most of us agree that an "on-path" attacker can read traf= fic.
They can problem inject traffic, and maybe even inject it in such a way tha= t
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 thos= e
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.=C2=A0 But it is unclear to me if MITM > on-path, or MITM =3D=3D= on-path.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--00000000000070ff2505ae575c2c-- From nobody Wed Sep 2 10:01:49 2020 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 ; 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 ) 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 ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 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 Mime-Version: 1.0 (1.0) Date: Wed, 2 Sep 2020 10:00:54 -0700 Message-Id: References: Cc: Michael Richardson , IETF SAAG In-Reply-To: To: Eric Rescorla 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 17:01:48 -0000 --Apple-Mail-95343884-0636-4C2A-B98E-0D9E495A2732 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The "on path" and "limited on path" can both read and inject traffic, but on= ly on path attackers can suppress traffic. An example of limited on path attackers are state level attackers who can ob= serve traffic at a variety of points, bring it to a monitoring facility, an= d inject traffic from there to interfere with targeted communications. TCP R= ST injection can easily work that way. -- Christian Huitema=20 > On Sep 2, 2020, at 9:45 AM, Eric Rescorla wrote: >=20 > =EF=BB=BF > QUIC ended up with a different taxonomy: > On-path > Off-path > Limited on-path (cannot delete) >=20 > -Ekr >=20 >=20 > https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-29#section= -21.12.3.1 >=20 >=20 >> On Wed, Sep 2, 2020 at 9:28 AM Michael Richardson = wrote: >>=20 >> 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 t= hat >> it beats the real traffic. >>=20 >> I think that most of us can agree that an off-path attacker can not read >> traffic. >>=20 >> 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 th= ose >> values. (Which at one point were very common) >>=20 >> A read-only on-path attacker that can read can be implemented with a MIRR= OR/SPAN port. >> Or as we learnt a few years ago with creative bending of fiber. >>=20 >> A firewall or router is a potential on-path attacker, but it can also dro= p 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 =3D=3D on-pa= th. >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail-95343884-0636-4C2A-B98E-0D9E495A2732 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable The "on path" and "limited on path" can bot= h read and inject traffic, but only on path attackers can suppress traffic.<= div>
An example of limited on path attackers are state level a= ttackers who can observe traffic at a variety of points, bring it to a monit= oring  facility, and inject traffic from there to interfere with target= ed communications. TCP RST injection can easily work that way.

-- Christian Huitema 

On Sep 2, 2020, at 9:45 AM, Eric Rescorla <ekr@rtfm.com> w= rote:

=EF= =BB=BF
QUIC ended up with a different taxonomy:
On-path
Off-path

On Wed, Sep 2, 2020 at 9:28 AM Mi= chael Richardson <mcr+ietf@san= delman.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 p= ackets.
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 =3D=3D o= n-path.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
_______________________________________________
saag m= ailing list
saag@ietf.org
https://www.ietf.o= rg/mailman/listinfo/saag
= --Apple-Mail-95343884-0636-4C2A-B98E-0D9E495A2732-- From nobody Wed Sep 2 10:37:17 2020 Return-Path: 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 F011B3A0C24 for ; Wed, 2 Sep 2020 10:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rOwU26Mszd_r for ; Wed, 2 Sep 2020 10:37:14 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBC13A0C0F for ; Wed, 2 Sep 2020 10:37:14 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id s92so220965ybi.2 for ; Wed, 02 Sep 2020 10:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=yYezpnV6wWkStdIc1M4NXuVVHTcXwFNUITHMVAsCOhI=; b=L4D2Pui49lAVfMoSqC6iH0pyIDYXlTKwxzoT41WQxt/9X+iHvHfG+SrJxP+XYD/UKu Xoda6t+JjKNDrksjSkWmyg/5d8LtOq9XypQDAYsOKOWr+LKq0ZzQWvq7hV0MvxMvvcEW +a6VqixGQwZCm+6FKUZrgKHeVJWHOEuViNd2mQYUwlSMEe+GWkNmksUyT3YQOdjrvq7I 2rfznSmOhY3ZoLOB1HQciKYn4QdM/OiBBtDeEixDrZT9nVliED0JpkpJ9jXmcAfE5FSi pVm2Kb6aXLW1s9/x58cRXH0mwVLBDoasbtUp0Dm0W/jwvy4Wt7CCaxa9rIfbMzCyZU76 PbYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=yYezpnV6wWkStdIc1M4NXuVVHTcXwFNUITHMVAsCOhI=; b=mRJOYKTzx8MjBqCbW/Hc0yxbsztSOQK3pz7IruO3yz+POCLDPrHukf/ByUXWnfOUsW +2ot1aGvqVdVBdCDDAQmBOPMQSBUIZh2pe9C/z39rGtHA5AR6uO8Be7rjiMTHs5nomj9 pRlLPVX+15fUPHDRye13m/0CyXV3W8wMWPcexg0VZOq7Xuhz/nE3Tp8alQ6ZYKAyRq4O 6fvLanCj6e9h78nSV86VQx833rS21E2j9qOsyOt627+kfb3ntvTBBCckWGQn0ebZrLoo 9Wy6LH8xtlzpRAtX5a+QPWl6Mpl41LEY6qVnkTA5IuDXKWAPOF8TaeW/TD7EOM9y7l7c 6RRw== X-Gm-Message-State: AOAM5328nbyueTtaanWiC8KFrlCZEuj+E9NW9WyNIIpp6Yb1zmSMq9jK 8uHjM2qP2u7PQ5W8+FnQygWdfN5CV1od2pyhEq0= X-Google-Smtp-Source: ABdhPJzECm1iGk7RbNPXaczkOmo5LR88AJom24gOfB/DZ2D502b8xvYVCW0K0ij0zWtPjlFFy1txC1RS7fgBbBeiwJY= X-Received: by 2002:a25:a85:: with SMTP id 127mr11467372ybk.327.1599068233324; Wed, 02 Sep 2020 10:37:13 -0700 (PDT) MIME-Version: 1.0 References: <4645.1599064072@localhost> In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Wed, 2 Sep 2020 12:37:02 -0500 Message-ID: To: Eric Rescorla Cc: Michael Richardson , IETF SAAG Content-Type: multipart/alternative; boundary="00000000000004df3805ae5816b4" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 17:37:16 -0000 --00000000000004df3805ae5816b4 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 2, 2020 at 11:45 AM Eric Rescorla wrote: > QUIC ended up with a different taxonomy: > On-path > Off-path > Limited on-path (cannot delete) > > Speaking of QUIC, I was surprised to read that QUIC is a UDP protocol. QUIC document talks about - connection establishment, -stream based multiplexed operation, -flow control, -ACK frame - on and on are all TCP-like features. My guess is that the mention of UDP-based was a sales-pitch :) Behcet > -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 > 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 , 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 > --00000000000004df3805ae5816b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 2, 2020 at 11:45 AM Eric = Rescorla <ekr@rtfm.com> wrote:
QUIC ended up with a differen= t taxonomy:
On-path
Off-path
Limited on-path = (cannot delete)


= Speaking of QUIC, I was surprised to read that QUIC=C2=A0is a UDP protocol.= QUIC document talks about=C2=A0
- connection establishment,
-stream based multiplexed operation,
-flow control,
-ACK frame
- on and on
are all TCP-like features.=C2= =A0

My guess is that the mention of UDP-based was = a sales-pitch :)

Behcet
-Ekr


<= a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-2= 9#section-21.12.3.1" target=3D"_blank">https://datatracker.ietf.org/doc/htm= l/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:<= br>

I think most of us agree that an "on-path" attacker can read traf= fic.
They can problem inject traffic, and maybe even inject it in such a way tha= t
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 thos= e
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.=C2=A0 But it is unclear to me if MITM > on-path, or MITM =3D=3D= on-path.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



_______________________________________________
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
--00000000000004df3805ae5816b4-- From nobody Wed Sep 2 12:19:53 2020 Return-Path: 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 76AEE3A0CEA for ; Wed, 2 Sep 2020 12:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 sSQ9vYzDS_pB for ; Wed, 2 Sep 2020 12:19:49 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A59D3A0CE9 for ; Wed, 2 Sep 2020 12:19:49 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id b12so413141lfp.9 for ; Wed, 02 Sep 2020 12:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EOJGMcxOE9ZgkyL9CRpRkDyqoJc09EyZDuawEijeFLE=; b=dJGKDkkKnWtpN8Vc9u72v8HGfuV9svYDnbZ83/VXiSwLxySSv/jwQy8HSXuF96RsI7 Iig6YAFLDbxat1o+z5G1zGLgskKvwb10astrGumqYeee5LMSJCiHd4KraA1iXbaBKWz0 7jnGxYDzjfigOd5ERd3GaLl+pw61jKsUHw/eORAyOxkmewvTTLaUiDG8F6nHOzwFBSPC vRgT8Ki7Z6Yd2ZaJ/rFeKiRuZxwQ2EymrS6NFi65zMEKksoCDoxkjd5/CLRyH6JYLvjf Nk/wkycz+QulpUI+jL2nYnnhlBD0RQXytnWgj7iJwBpp3SwdQyFvShWKV1NRKwwkzcwD +tEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EOJGMcxOE9ZgkyL9CRpRkDyqoJc09EyZDuawEijeFLE=; b=bsY+mLFaL2L3sl40SVE/mDpB47KAdr4ztRW/0EuQbLvGzDK4cHFH6ibL4u7Y1/Krb0 +YPKIN7lYdpnlFwXDqLPhge2F+phD6EmISCglF6b8YMMlghBxn1hiH2h2o4JpKBAdX6/ yx7xge3cmGGXKr6Tw9Q74ZMc1KCCwiwOAMbEh/ETBZmA+0g3N/kGSvrzVr0SUn4jkglO mie3UJauR4ZhQ+rUWwFPWhi0ppr+kH666EMiSDgAD+7GgYMHehLD7sD0zZ86SE4dEprI Sd9mjIftj0bb9Dm1KPcbX+7vg8cOQPJXbPPnEx4sWeNwrST3yt2wKFGZw6hX8JqLjrsK 6Fgg== X-Gm-Message-State: AOAM531vwOzoK+FSpPhnVX6qFCkIvw9xU7YO55gcy6HGUHP4QmRTG4MK V4y597tHQkfrVl8iF3qdtyoQmeKDhpu4D8TPbny6Ng== X-Google-Smtp-Source: ABdhPJwAxVB2ogsC9hGgSVaxzJJxHzeq8CikD4ymqvHvHPeB+Ks/P1h+e+sKqCT4ZfbHkfYPzdkNa6bAnVmagqbzFaA= X-Received: by 2002:a19:e57:: with SMTP id 84mr3731409lfo.161.1599074387755; Wed, 02 Sep 2020 12:19:47 -0700 (PDT) MIME-Version: 1.0 References: <4645.1599064072@localhost> In-Reply-To: From: Eric Rescorla Date: Wed, 2 Sep 2020 12:19:11 -0700 Message-ID: To: sarikaya@ieee.org Cc: Michael Richardson , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000da1b3e05ae598482" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 19:19:51 -0000 --000000000000da1b3e05ae598482 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 2, 2020 at 10:37 AM Behcet Sarikaya wrote: > > > On Wed, Sep 2, 2020 at 11:45 AM Eric Rescorla wrote: > >> QUIC ended up with a different taxonomy: >> On-path >> Off-path >> Limited on-path (cannot delete) >> >> > Speaking of QUIC, I was surprised to read that QUIC is a UDP protocol. > QUIC document talks about > - connection establishment, > -stream based multiplexed operation, > -flow control, > -ACK frame > - on and on > are all TCP-like features. > > My guess is that the mention of UDP-based was a sales-pitch :) > QUIC is a next-generation transport protocol that runs *over* UDP. In an earlier era, it might have been designed to run over IP as SCTP was, but for operational reasons (firewall/NAT traversal and the ability to iterate rapidly), it is run over UDP instead. -Ekr Behcet > >> -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 >> 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 , 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 >> > --000000000000da1b3e05ae598482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 2, 2020 at 10:37 AM Behce= t Sarikaya <sarikaya2012@gmail= .com> wrote:


On Wed, Sep 2, 2020 at 11:45 AM E= ric Rescorla <ekr@rtfm= .com> wrote:
QUIC ended up with a different taxonomy:
On-path
Off-path
Limited on-path (cannot delete)


Speaking of QUIC, I = was surprised to read that QUIC=C2=A0is a UDP protocol. QUIC document talks= about=C2=A0
- connection establishment,
-stream based = multiplexed operation,
-flow control,
-ACK frame
<= div>- on and on
are all TCP-like features.=C2=A0

My guess is that the mention of UDP-based was a sales-pitch :)

QUIC is a next-generation tr= ansport protocol that runs *over* UDP. In an earlier era, it might have bee= n designed to run over IP as SCTP was, but for operational reasons (firewal= l/NAT traversal and the ability to iterate rapidly), it is run over UDP ins= tead.

-Ekr

Behcet
-Ekr


<= a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-2= 9#section-21.12.3.1" target=3D"_blank">https://datatracker.ietf.org/doc/htm= l/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:<= br>

I think most of us agree that an "on-path" attacker can read traf= fic.
They can problem inject traffic, and maybe even inject it in such a way tha= t
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 thos= e
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.=C2=A0 But it is unclear to me if MITM > on-path, or MITM =3D=3D= on-path.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



_______________________________________________
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
--000000000000da1b3e05ae598482-- From nobody Wed Sep 2 12:33:10 2020 Return-Path: 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 771C23A0D41 for ; Wed, 2 Sep 2020 12:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 QzzOj_C52i8y for ; Wed, 2 Sep 2020 12:33:07 -0700 (PDT) Received: from fossa.birch.relay.mailchannels.net (fossa.birch.relay.mailchannels.net [23.83.209.62]) (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 376D73A0D3F for ; Wed, 2 Sep 2020 12:33:07 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 165637011FC; Wed, 2 Sep 2020 19:33:06 +0000 (UTC) Received: from pdx1-sub0-mail-a40.g.dreamhost.com (100-96-23-39.trex.outbound.svc.cluster.local [100.96.23.39]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A56EF701394; Wed, 2 Sep 2020 19:33:05 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a40.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.9); Wed, 02 Sep 2020 19:33:06 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Lonely-Quick: 15c6b7af3c66a203_1599075185907_9076568 X-MC-Loop-Signature: 1599075185907:102620037 X-MC-Ingress-Time: 1599075185906 Received: from pdx1-sub0-mail-a40.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a40.g.dreamhost.com (Postfix) with ESMTP id 6EB7980A80; Wed, 2 Sep 2020 12:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=PyKB3DvMTeT8py nEv0KQ6ybyT90=; b=X3TsD1wNHxe5TQ1l7uTUq6jMJUGLTded9xSTerK5BJOh5f gpTa0h+4PGHAVSJSX+XhBQF9zkGah6Vbt/1DJBqAOwLAkVSFekDC+MpwKAvp1R8O 4l1SGC3L5+DkAPBh2ZcaRQ+xhDDvEHvoMl20tVDfXHSwpXGqCITa5/5VwuAeE= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a40.g.dreamhost.com (Postfix) with ESMTPSA id D2C2180A7F; Wed, 2 Sep 2020 12:33:03 -0700 (PDT) Date: Wed, 2 Sep 2020 14:33:01 -0500 X-DH-BACKEND: pdx1-sub0-mail-a40 From: Nico Williams To: Michael Richardson Cc: saag@ietf.org Message-ID: <20200902193300.GW3100@localhost> References: <4645.1599064072@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4645.1599064072@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrudefledgudefkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 19:33:08 -0000 On Wed, Sep 02, 2020 at 12:27:52PM -0400, Michael Richardson wrote: > 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. To me on-path means physically or logically (e.g., after DNS spoofing or route take over) in the path. MITM is about being in the middle at some higher layer than IP. For example, in TLS, which you can do if you can subvert a CA trusted by the client. You can have an on-path (physically) attacker who nonetheless cannot successfully mount an MITM attack on TLS traffic it gets to see and even alter. Nico -- From nobody Wed Sep 2 13:11:33 2020 Return-Path: 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 F16B43A0E14 for ; Wed, 2 Sep 2020 13:11:32 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 LCMn3AIPHu5R for ; Wed, 2 Sep 2020 13:11:30 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19B33A0E08 for ; Wed, 2 Sep 2020 13:11:30 -0700 (PDT) Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BhZp845Q7zyRG; Wed, 2 Sep 2020 22:11:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <20200902193300.GW3100@localhost> Date: Wed, 2 Sep 2020 22:11:27 +0200 Cc: Michael Richardson , saag@ietf.org X-Mao-Original-Outgoing-Id: 620770287.8084871-08e3f9329164d44e82d88cc13785c47e Content-Transfer-Encoding: quoted-printable Message-Id: <11624BD0-63D7-42E4-8852-73AD3787DA2D@tzi.org> References: <4645.1599064072@localhost> <20200902193300.GW3100@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 20:11:33 -0000 On 2020-09-02, at 21:33, Nico Williams wrote: >=20 > To me on-path means physically or logically (e.g., after DNS spoofing = or > route take over) in the path. >=20 > MITM is about being in the middle at some higher layer than IP. Right. A MITM attack can start before there is "a path". Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Sep 15 11:32:55 2020 Return-Path: X-Original-To: saag@ietf.org Delivered-To: saag@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8F3A16C9; Tue, 15 Sep 2020 11:32:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: saag-chairs@ietf.org, kaduk@mit.edu, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160019477382.25043.11988871160629677854@ietfa.amsl.com> Date: Tue, 15 Sep 2020 11:32:53 -0700 Archived-At: Subject: [saag] saag - New Meeting Session Request for IETF 109 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2020 18:32:54 -0000 A new meeting session request has just been submitted by Benjamin Kaduk, a Chair of the saag working group. --------------------------------------------------------- Working Group Name: Security Area Open Meeting Area Name: Security Area Session Requester: Benjamin Kaduk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: Chair Conflict: ace acme cfrg cose curdle dots emu gnap i2nsf ipsecme kitten lamps mile mls oauth rats sacm secdispatch secevent suit teep tls tokbind trans privacypass Technology Overlap: dmarc dprive sidrops uta pearg Key Participant Conflict: irtfopen People who must be present: Roman Danyliw Benjamin Kaduk Resources Requested: Special Requests: Normally we ask for Thursday "after lunch", but for the virtual meeting any time on Thursday should be fine. --------------------------------------------------------- From nobody Tue Sep 29 16:00:17 2020 Return-Path: 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 07E7B3A1392 for ; Tue, 29 Sep 2020 16:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 OYqTnvnKUe2L for ; Tue, 29 Sep 2020 16:00:15 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 ED24F3A1395 for ; Tue, 29 Sep 2020 16:00:14 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08TN0BW3009485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 29 Sep 2020 19:00:13 -0400 Date: Tue, 29 Sep 2020 16:00:10 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20200929230010.GC89563@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] shorthand for iPAddress subjectAltName? X-BeenThere: saag@ietf.org 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: Tue, 29 Sep 2020 23:00:16 -0000 Hi all, RFC 6125 defines a number of "identifier type"s for X.509 certificate naming fields, e.g., DNS-ID for dNSName, etc., but does not list one for the iPAddress SAN. Having such a term seems like it would be useful in order to have a parallel expository structure when referring to (e.g.) DNS-ID and . I'm currently reviewing a document that proposes NETWORK-ID (for "network address") but am planning to counter-propose "IPADDR-ID". Does anyone else have thoughts on what a good practice here would be? Thanks, Ben From nobody Wed Sep 30 09:32:52 2020 Return-Path: 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 78CE83A0B38 for ; Wed, 30 Sep 2020 09:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Qn3N_Yl77tDO for ; Wed, 30 Sep 2020 09:32:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85453A0B57 for ; Wed, 30 Sep 2020 09:32:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F3DA0389EA; Wed, 30 Sep 2020 12:37:44 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f5dDxyF5CdEs; Wed, 30 Sep 2020 12:37:40 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BB4AF389E9; Wed, 30 Sep 2020 12:37:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9F7F61D5; Wed, 30 Sep 2020 12:32:43 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: saag@ietf.org In-Reply-To: <20200929230010.GC89563@kduck.mit.edu> References: <20200929230010.GC89563@kduck.mit.edu> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] shorthand for iPAddress subjectAltName? X-BeenThere: saag@ietf.org 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: Wed, 30 Sep 2020 16:32:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: > to (e.g.) DNS-ID and . I'm currently reviewing a > document that proposes NETWORK-ID (for "network address") but am > planning to counter-propose "IPADDR-ID". Does anyone else have > thoughts on what a good practice here would be? I agree that NETWORK-ID could mis-construed, and the more specific name is better. An FQDN could be considered a "network address", and I'm sure there are people who feel their @mcr314 twitter handle is the one and true "netwo= rk address". There will naturally be confusion if this is an IP(v4)ADDR-ID or IPv6ADDR-I= D, while iPAddress SAN deals with both. I think we can live with that though. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEyBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl90sysACgkQgItw+93Q 3WWwtQf3T00Cd+ZGhYkzuRUttEc+1fE7QifqxI/SKESY3PcheaxhU7HYUgGu+5Wi WWhCbkHjgNOvgGSo1HLziX5poTTwlefCxLPCqtF+MQOIMf+/X9QEmxWeR4Z7UZ6A 2i4ThQcIRgpykGQnAfzr8d4YGRKuGxUFN1ILSxHn/qcWk+IjY7Mebibb4xFwy/gq oXb3yA+gacoYG42bsdcSvelAlrD0BmrEpBxiH6k0Dq5y4KSdneRcdMV1tMoSGh9T E/FUsCu3pa22TumkE7dENml0AY1eT21LyO6f6zZ/mY7r5ZKmBP6fbyh3GNZVV/0Z EsCBHn2t5yRXp6UBsfHfN28VJNgU =BiBp -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 30 21:37:35 2020 Return-Path: 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 5B62F3A0A2C for ; Wed, 30 Sep 2020 21:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_PASS=-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 bUdbJSpoiWrZ for ; Wed, 30 Sep 2020 21:37:33 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 559AE3A0A2B for ; Wed, 30 Sep 2020 21:37:33 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QHI0KDLTA6L1X@wwwlocal.goatley.com> for saag@ietf.org; Wed, 30 Sep 2020 23:37:33 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QHI00IGRA2VA9@trixy.bergandi.net> for saag@ietf.org; Wed, 30 Sep 2020 21:35:19 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 30 Sep 2020 21:35:19 -0700 Date: Wed, 30 Sep 2020 21:37:31 -0700 From: Dan Harkins In-reply-to: <20200902193300.GW3100@localhost> To: saag@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <4645.1599064072@localhost> <20200902193300.GW3100@localhost> X-PMAS-Software: PreciseMail V3.3 [200930] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 04:37:34 -0000   So what is an "active attacker" then? When people talk about protocol security it is in the presence of a powerful attacker who can schedule protocol sessions, and also view, modify, drop, and replay packets that constitute the protocol. I always assumed a MITM was just an "active attacker" in this sense.   Seems we should be very careful when saying exactly what capabilities this "on path attacker" has if it's not the same as a MITM/"active attacker". And if these capabilities are a subset of the traditional "active attacker" then what is the point of making the distinction?   regards,   Dan. On 9/2/20 12:33 PM, Nico Williams wrote: > On Wed, Sep 02, 2020 at 12:27:52PM -0400, Michael Richardson wrote: >> 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. > To me on-path means physically or logically (e.g., after DNS spoofing or > route take over) in the path. > > MITM is about being in the middle at some higher layer than IP. For > example, in TLS, which you can do if you can subvert a CA trusted by the > client. > > You can have an on-path (physically) attacker who nonetheless cannot > successfully mount an MITM attack on TLS traffic it gets to see and even > alter. > > Nico From nobody Wed Sep 30 23:29:14 2020 Return-Path: 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 08D6F3A0AE6 for ; Wed, 30 Sep 2020 23:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 22C2a-hwYW6o for ; Wed, 30 Sep 2020 23:29:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24ADF3A0AE3 for ; Wed, 30 Sep 2020 23:29:08 -0700 (PDT) Received: from [100.68.105.134] (ip-109-41-64-230.web.vodafone.de [109.41.64.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4C239t1pQPzycs; Thu, 1 Oct 2020 08:29:06 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-510979BC-662E-4470-AE20-E18EEC6DF623 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Carsten Bormann In-Reply-To: Date: Thu, 1 Oct 2020 08:29:05 +0200 Cc: saag@ietf.org Message-Id: <4CD0D081-806A-4303-85F2-7F6F26028539@tzi.org> References: To: Dan Harkins X-Mailer: iPhone Mail (18A393) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 06:29:13 -0000 --Apple-Mail-510979BC-662E-4470-AE20-E18EEC6DF623 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable An active attacker actively changes the situation. Need not be on path, trad= itional blind session hijacking is an active attack. A Janus attack (MITM) o= bviously is active.=20 Sent from mobile, sorry for terse > On 1. Oct 2020, at 06:37, Dan Harkins wrote: >=20 > =EF=BB=BF > So what is an "active attacker" then? When people talk about protocol > security it is in the presence of a powerful attacker who can schedule > protocol sessions, and also view, modify, drop, and replay packets that > constitute the protocol. I always assumed a MITM was just an "active > attacker" in this sense. >=20 > Seems we should be very careful when saying exactly what capabilities > this "on path attacker" has if it's not the same as a MITM/"active > attacker". And if these capabilities are a subset of the traditional > "active attacker" then what is the point of making the distinction? >=20 > regards, >=20 > Dan. >=20 >> On 9/2/20 12:33 PM, Nico Williams wrote: >>> On Wed, Sep 02, 2020 at 12:27:52PM -0400, Michael Richardson wrote: >>> A firewall or router is a potential on-path attacker, but it can also dr= op packets. >>> What do we call this? >>> This was historically called a MITM, and it implied all the attributes o= f >>> on-path. But it is unclear to me if MITM > on-path, or MITM =3D=3D on-p= ath. >> To me on-path means physically or logically (e.g., after DNS spoofing or >> route take over) in the path. >>=20 >> MITM is about being in the middle at some higher layer than IP. For >> example, in TLS, which you can do if you can subvert a CA trusted by the >> client. >>=20 >> You can have an on-path (physically) attacker who nonetheless cannot >> successfully mount an MITM attack on TLS traffic it gets to see and even >> alter. >>=20 >> Nico >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-510979BC-662E-4470-AE20-E18EEC6DF623 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable An active attacker actively changes the sit= uation. Need not be on path, traditional blind session hijacking is an activ= e attack. A Janus attack (MITM) obviously is active. 

Sent from mobile, sorry for ters= e

On 1. Oct 2020,= at 06:37, Dan Harkins <dharkins@lounge.org> wrote:

=EF=BB=BF  So what is an "active attacker" then? When people talk about p= rotocol
security it is in the presence of a powerful attacke= r who can schedule
protocol sessions, and also view, modify,= drop, and replay packets that
constitute the protocol. I al= ways assumed a MITM was just an "active
attacker" in this se= nse.

  Seems we should be very careful= when saying exactly what capabilities
this "on path attacke= r" has if it's not the same as a MITM/"active
attacker". And= if these capabilities are a subset of the traditional
"acti= ve attacker" then what is the point of making the distinction?

  regards,

  D= an.

On 9/2/20 12:33 PM, Nico Williams wrote= :
On Wed, Sep 02, 2020 at 12:27:52= PM -0400, Michael Richardson wrote:
A firewall or router is a potential o= n-path attacker, but it can also drop packets.
What do we c= all this?
This was historically called a MITM, and it impl= ied all the attributes of
on-path.  But it is unclear= to me if MITM > on-path, or MITM =3D=3D on-path.
=
To me on-path means physically o= r logically (e.g., after DNS spoofing or
route take over) in the path.

MITM is about being in the middle at some higher layer than IP. &nbs= p;For
example, in TLS= , which you can do if you can subvert a CA trusted by the
client.

You can have an on-path (physically) attacker who nonetheless cannot
successfully mount an MI= TM attack on TLS traffic it gets to see and even
alter.

Nico

________________________________= _______________
saag mailing list
saag@ietf.= org
https://www.ietf.org/mailman/listinfo/saag
= --Apple-Mail-510979BC-662E-4470-AE20-E18EEC6DF623--