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

Eric Rescorla <ekr@rtfm.com> Wed, 02 September 2020 19:19 UTC

Return-Path: <ekr@rtfm.com>
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 <saag@ietfa.amsl.com>; 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 <saag@ietfa.amsl.com>; 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 <saag@ietf.org>; Wed, 2 Sep 2020 12:19:49 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id b12so413141lfp.9 for <saag@ietf.org>; 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> <CABcZeBNWf=8TU_tJK5rKyh_Veaa5L0jhV9qkvL7M-k-BaNYoRA@mail.gmail.com> <CAC8QAcc8cq5ff0DMD_ArSYO7E8hg1M-RDFWaJtkf8aS1j_dSeA@mail.gmail.com>
In-Reply-To: <CAC8QAcc8cq5ff0DMD_ArSYO7E8hg1M-RDFWaJtkf8aS1j_dSeA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 2 Sep 2020 12:19:11 -0700
Message-ID: <CABcZeBOez2HOT5qUvN3EBmJG7W7LQGerKyR+_5eTxyar-EYhbQ@mail.gmail.com>
To: sarikaya@ieee.org
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000da1b3e05ae598482"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/CcADWwCUBWjOzitJBH8-dCboR6k>
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 19:19:51 -0000

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

>
>
> On Wed, Sep 2, 2020 at 11:45 AM Eric 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 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 <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>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
>>
>