Re: [Mud] Convening MUD calls, + next steps

"M. Ranganathan" <mranga@gmail.com> Mon, 20 May 2019 14:07 UTC

Return-Path: <mranga@gmail.com>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3987E12017D for <mud@ietfa.amsl.com>; Mon, 20 May 2019 07:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WRofURP2_7El for <mud@ietfa.amsl.com>; Mon, 20 May 2019 07:07:04 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 AC0DE12012C for <mud@ietf.org>; Mon, 20 May 2019 07:07:04 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id u2so11123557ioc.4 for <mud@ietf.org>; Mon, 20 May 2019 07:07:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=89WlCri2bneWCRr+0eG92UWQTpj7oBUUN0XrfNh9Kb0=; b=tNSw1DZVtltHCe+ZSgxDDHPbDnfV/JIzwzvMkLApcHONKSFMZApWhGswOy1vXIQgjD A2g4yDzuTt7S4LsOJggEaoXdLqAlQWnqo9NzopfmFDLSx9BxwPsjljbNXCXJ0DVWgdCL SE/Mk2JQFH6amfo0UrRyD3FsVQG8hIYWNC6Y7CHo7zY8x7hFeUVi+awugI2QA0bC4RwD oQKgXSy3E7b6TnNcwWoMxjbnKJac40hu4NXeOOL4+DYV7bTsNBZCG4DAoTrxHZLaWoVp KkAaca90sKYmygX4l6rNLLTJJHcKn8IbPfhpBa/oD8kKqnIEP/+mUWjMfZaIdfiUDkjf YXbw==
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=89WlCri2bneWCRr+0eG92UWQTpj7oBUUN0XrfNh9Kb0=; b=QF+VeeWpj6NcPjufC4XmWcFlOz6/pfKkHDw5n6TzeHmjjFlRrrni1fCCc5Rkxc6Nes iX7gFP6OaApiLStjR0X5KO+PpLCGVBGqW7AChJywlpaZ+sVoU1Np+3NIep6vNAKTQ8r5 fI01BqFWtOIo3NvC5U2wSZpK/UbJmfoTGS0gvkEu5wQ34GwtdMYgzBKSc1dEpX1yfAeT wAMk2MrSIIjsuev4aL3X/C/a/Ku3QH1fztxqmyF0Hmu2hDJlHQiMaukTT8O6S6PWIiux K0+Gfpf+qdW31Jf2rVvCSeaml2QIJ899lrjZ6NXEkTEppPRHBaLHetXdrqP4l164QCWs YbmQ==
X-Gm-Message-State: APjAAAVaoGxP6bqIOdJoq38rSeQ2B/w7H05KViauZF+0GRxz/uyW3mub /LYFFuvyAXjUzlsGNTj2Gj83xQG5rfIB5alhtBU=
X-Google-Smtp-Source: APXvYqx89TKRIuWZrlq6Ldv7eOIJHXyhp38+MJRyIu1agyc/ZoV0BmaPo2r03cFaEP9oxff1jxGPSLyTSiQYAq5BnWw=
X-Received: by 2002:a05:6602:214f:: with SMTP id y15mr5174502ioy.102.1558361223703; Mon, 20 May 2019 07:07:03 -0700 (PDT)
MIME-Version: 1.0
References: <5B10945F-EFE2-4021-9650-F010A737BA1D@isoc.org> <F9F696B9-1DAC-4070-B85F-780C841FCC62@cisco.com> <19433.1555006746@localhost> <ABA471C2-D547-4BA0-875C-CF1B7CD61722@cisco.com> <D0A4C670-E9A3-4DA8-8D57-C9D96B7D211F@nist.gov> <AFB482B9-D747-420B-879D-D20E5D9C8BC1@cisco.com> <CAHiu4JPjwuzHPhdDDzNahcngkkOOkSnerFwGx=QH9vbUJ1H8=g@mail.gmail.com> <10007.1555379966@localhost> <CAHiu4JO-iY1h02pKaJzP=eU4WvTn_9HpghnPdynrxEupwh8CPw@mail.gmail.com> <F72774E9-E630-4EC7-B6CA-78F963AEE444@cisco.com> <CAHiu4JNs1D9S8kMMnH2n5VeyHensbjE4Dg_XttZjoGMuHwR+FQ@mail.gmail.com> <11306A54-162F-4EA3-803B-FC2D1BB7D4E6@cisco.com> <30445.1557872022@localhost> <CAHiu4JM9swU=HeG4kgQUiXFXUSQMZwh_yzOFqmp1dR_sCTunow@mail.gmail.com>
In-Reply-To: <CAHiu4JM9swU=HeG4kgQUiXFXUSQMZwh_yzOFqmp1dR_sCTunow@mail.gmail.com>
From: "M. Ranganathan" <mranga@gmail.com>
Date: Mon, 20 May 2019 10:06:26 -0400
Message-ID: <CAHiu4JO=2m6HZ6Ep5hp_JhBE+uPCiEDCj7AfGygf-70aWasLtA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: mud@ietf.org, Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary="0000000000002bb48f0589523fe4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/xmmxXjxM3tXzDyIHHOfQ1JXCgC8>
Subject: Re: [Mud] Convening MUD calls, + next steps
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2019 14:07:07 -0000

Are there any standard logging formats to report "misbehavior"?  Maybe just
use syslog (RFC 3164)?

What should the tuning parameters be? I was thinking, frequency of sampling
and packet rate estimation.

I came across the following which looked interesting:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/monitor_nsel.html#wp1111174%0A

On Tue, May 14, 2019 at 8:22 PM M. Ranganathan <mranga@gmail.com> wrote:

>
>
> On Tue, May 14, 2019 at 6:13 PM Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
>
>>
>> Eliot Lear <lear@cisco.com> wrote:
>>     mr> MUD is a series of "ACCEPT" rules followed by an implicit DROP
>> rule. So
>>     mr> how can we know that a specific MUD rule caused a packet to be
>> dropped?
>>     mr> All we know when the packet is dropped (or marked for drop) is
>> that NO
>>     mr> mud rule allowed the packet to proceed.
>>
>>     > On the whole this is generally true. The fact that the packet was
>> dropped
>>     > means that NONE of the accept rules were met, and that’s a lot of
>> information
>>     > right there. ie, my-controller, same-manufacturer etc didn’t match,
>> or they
>>     > matched a reject rule. Do others have thoughts there?
>>
>> But the rules aren't actually fully specific.
>> They get instantiated:
>>   1) source is the device (by... L2? L3? depends upon implementation)
>>   2) destination is an IP, but rule is by name, so how did DNS resolve?
>>
>> It would be ideal if one could identify packets that would have matched if
>> only the source was different, or the destination was resolved
>> differently.
>> This requires a bit of fuzzy matching against the drop-log.
>>
>> That probably accounts for 9 out 10 situations where packets were dropped
>> that were not really malicious.
>>
>
> If we put a Source MAC/IP classification to activate a notification action
> in place of the implied drop, we could notify on the basis of
> those classifications.
>
> The implementation mechanism that is used to classify packets is not so
> relevant IMHO.
>
> What is important is that the packets, get classified and then get dropped
> because they
> misbehave. The MUD rules are stated on the basis of these classifications.
>
> So while you cannot state that a specific MUD rule caused a drop, you CAN
> state that a particular classification of packets caused a drop.
>
> Why not use the same classification mechanism that MUD uses to notify that
> a packet originated by the
> MUD-enabled device did something that the MUD rules disallowed?
>
> This would allow the administrator to select the notifications that he
> wants to provide to the manufacturer.
>
>
>
>
>>
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>>
>>
>>
>
> --
> M. Ranganathan
>
>

-- 
M. Ranganathan