Re: [Smart] [Secdispatch] New Version Notification for draft-lazanski-smart-users-internet-00.txt

Eric Rescorla <ekr@rtfm.com> Mon, 15 July 2019 11:32 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: smart@ietfa.amsl.com
Delivered-To: smart@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C8B120077 for <smart@ietfa.amsl.com>; Mon, 15 Jul 2019 04:32:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 fnPCmGRsMJ9m for <smart@ietfa.amsl.com>; Mon, 15 Jul 2019 04:32:38 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 E0EDF120018 for <smart@irtf.org>; Mon, 15 Jul 2019 04:32:37 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id k18so15797040ljc.11 for <smart@irtf.org>; Mon, 15 Jul 2019 04:32:37 -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=U8ozZZyh4ljfD75AvyK62E63F88X745s9RGGlFyDHsc=; b=Ff5x4rhv8in9Rvih9hoFFJSCoQquvMDCK9IvN4pWrddBssVSOB+8DbTbV/ZdBDxmeY rnXGiA183aDbj+WOuCMAjTS3TJRo9paSOET7eqprldCPksMvPj5/ebOtPy5DgLwH05Eo ciUvmZ0JWG7OfmUGK3kP07tvU0MnI60lpxjQ827gsoS2Z9sVgDqiY5MbfidUmkvihtZw StwBSz/U/jPkgVfLmkaWlHMbmG4ANOv6UUTvSF9RHpiBEr5uXTvLXTYhPgsvS7Bx5vR0 qJFvF9S/fBcgNJEb6FoSg5U8TqbI0UBYMMATd4x3zUSSKjI3CkeywEGz1UXAZZFtS5aq zKIw==
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=U8ozZZyh4ljfD75AvyK62E63F88X745s9RGGlFyDHsc=; b=Hj5n2+3O+KepWmHpBLM0mChb1gbmnH1K0KNpUyQcUS3bqEQMqlNZ8jZ1txUa+dqgYM 87x+6VQClsdwTTR1QkZ+BxXFPo9Rq230uZLnmdBPHoiDyVI2CVfV1D7/4smdqWSogq41 wMVaVhl7sTtKe+t2DalSCKyLpTT20RxCWhPVmJW9Xyr7R3UmnZU0hBuyqiaTq16IysJI 7393ZbDqbGIvT/DJ424FL4j5v2nffC3qOZzbHy8C4hyxW8K9RdBVE7mjgYac/gptOVn4 7aAllXcR7WFWKZCeLDacX6XMNmqtMUcaFPM8wEsuxDQLkkQrVhU7XKdMY+VfHk3/2s/2 fcZQ==
X-Gm-Message-State: APjAAAUdlWS5k0c8h3PiAMoCeC6cCiF8USmwnpv1w5dsx/CM+iYDpBRa ypxSE4iJx+JYY0blRbnPai9aRkIdH2kCtp6GhpM=
X-Google-Smtp-Source: APXvYqx7Y+YwVvkVrC0bZbS7FvcR+lEFi2yqWoNatPF0h+R+JmS3o6Syh0P4af3167Qqf3QGFI6hF8ZckXniMneD7Lk=
X-Received: by 2002:a2e:9cd4:: with SMTP id g20mr13068538ljj.205.1563190356173; Mon, 15 Jul 2019 04:32:36 -0700 (PDT)
MIME-Version: 1.0
References: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <CAMm+Lwh3KW6ZBbMktwmLcKyY8=_ysLYJF_7MsAuiOat6baQ=Kg@mail.gmail.com> <B551EF79-7E6E-4C4E-ADCA-6538F7972222@gmail.com> <CAMm+Lwg+2RFiXK43nJv7pD3OgM8y=ziVYxBkXD3F2kJyz37SxQ@mail.gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <CAHbuEH5WUv-a4nKt5YAZosO-vE773Jh3xn1+-hA=4J7RBERc3g@mail.gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> <CABcZeBNwmitpkJn0fCbNHOJtJ25yXdk6i6U9wK0a-9hwK1Tqcw@mail.gmail.com> <D484DBE1-8136-42C6-882C-307DC48E06DE@cisco.com>
In-Reply-To: <D484DBE1-8136-42C6-882C-307DC48E06DE@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 15 Jul 2019 04:31:58 -0700
Message-ID: <CABcZeBPrhs+UmWgEu7M8g_6j3+Yzp0+wkz0_OTtvnuUmCUFwSw@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, smart@irtf.org, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Dominique Lazanski <dml@lastpresslabel.com>, IETF SecDispatch <Secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e58d53058db69dc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/smart/lQDXcRkS25CdSTUicaNGyXRo6Z8>
Subject: Re: [Smart] [Secdispatch] New Version Notification for draft-lazanski-smart-users-internet-00.txt
X-BeenThere: smart@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Stopping Malware And Researching Threats <smart.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/smart>, <mailto:smart-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smart/>
List-Post: <mailto:smart@irtf.org>
List-Help: <mailto:smart-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/smart>, <mailto:smart-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 11:32:40 -0000

On Mon, Jul 15, 2019 at 1:11 AM Eliot Lear <lear@cisco.com> wrote:

> Hi Eric,
>
> On 14 Jul 2019, at 23:24, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Similarly, I don't think that the kinds of botnet attacks described
> in Section 3 are out of scope for 3552, though I see how it could
> be read this way. However I think that the idea of a malicious
> counterparty is clearly in scope if we assume that the attacker
> controls the network.
>
>
>
> When you say “network” do you mean the botnet or the wired network
> connecting devices?
>

Well, from the perspective of the receiver of traffic, these are kind of
the same thing, because you're just receiving packets.

I agree it's a bit of an awkward fit, and I wish 3552 talked more about
compromised counterparties -- this is mostly due to my comsec orientation,
I agree -- but I'm not sure that it would change what work we do...

-Ekr

 The former is where I and most people would argument most of the trouble
> stems from: since a great many attacks are coming from batted devices.  I
> seem to recall that we shut down a botnet some time ago that had more
> devices than all of the Internet infrastructure at all major carriers
> combined (it was in the millions).
>



>
> Here too, I wouldn't expect 3552 to be deployed
> to preclude that kind of work; we have done plenty of anti-DoS work
> in IETF (whether it is good enough is a different story).
>
>
>
> And I would expand that to cover not just DoS, but other forms of attack.
>
> To your point on the E in IETF, I agree that there needs to be clarity on
> what E is needed. As I wrote elsewhere, I would be happy with quite a bit
> more R from the sister organization.
>
> Eliot
>
>