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

"M. Ranganathan" <mranga@gmail.com> Wed, 15 May 2019 00:23 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 E445212004C for <mud@ietfa.amsl.com>; Tue, 14 May 2019 17:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 FdO0WwsEDOjC for <mud@ietfa.amsl.com>; Tue, 14 May 2019 17:23:33 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 B85C012003E for <mud@ietf.org>; Tue, 14 May 2019 17:23:33 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id q21so747608iog.13 for <mud@ietf.org>; Tue, 14 May 2019 17:23:33 -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=60Pw+knh4HNYj1vKIz8ktLfsECVXQkMATiktdUlcfr0=; b=ryTvP5izRAGLqfkccKFKEFMm8Bzoe1HbTSHdR2AiQpfLTZ1LrLJYlUFgEKK2F7D0Hd j2SoX1+Gh32GIQK4uto1W3gw4Ca8MgEuGQ8ZAxO4cotxINGNscsNqqLeMO69VzyHzGRL 2ke0SYJS+VnlmOhhinYm2BU97kanTTKzC7N0MQAW7QAl0rwxazlkUZ84tV9csc9ndtgj AbQD+45VZhb5fx945+AFWhmRtUcFuBsSZwEC7pjq+167u40NiYiu+GzrEq4FtVFNwb9Z w3YIhWfd54F4eepAIvzlmQiCYURlv9pIocnnWoEz5i6lrqBGzhPjNR7agNlwG8jRmpD4 9z5Q==
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=60Pw+knh4HNYj1vKIz8ktLfsECVXQkMATiktdUlcfr0=; b=nQtvYBoBFqhZg9j/qbqVWsdH3+0IaeSDUS3XCkcYawz2+CDo5x1hEzPXN1Q7TtLcrl q/UQEvxy/A0vFfsYuHi/c8dPI0jugeY3wojNjWaPAbmRNADXTKAh5mqdgQ3yaJDdBSUg blbFeqVHKnhIAyJwH2T9C0In4hyKK2b4MBEUmiDLc2ZnoPC82eDCOOq8tkSdmcoaC2bZ E9nDKqwICZx4Rd/+M1jZOyGLlve9dTGHuhwyPxl69yE1KNFHGLT3LA0rB4tx6L5AjGSD TtWiqjvm/B5eFPeeyk4/oEjbtAZ+D8HWZ+KFftnU1CV6DXqRaxZ+sWZ+Wuy0A/BC1CBl gHlg==
X-Gm-Message-State: APjAAAUGadr1pBQVt9+GIwKYzeShg5c11yXQhl4niTQhUhwPRtYKjW46 LghN8Onf4kb46fzKZNGorMJINjBCsH5zjD09p6s=
X-Google-Smtp-Source: APXvYqyjMoq0TGBg6E1OHj1WwF6hOenrR7J2KRrhiTizAE/0tsLC2uyq6nzTdWxKme47BhgyU2qxFKucDdG/p4MQ4k8=
X-Received: by 2002:a5e:8904:: with SMTP id k4mr17440430ioj.264.1557879812783; Tue, 14 May 2019 17:23:32 -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>
In-Reply-To: <30445.1557872022@localhost>
From: "M. Ranganathan" <mranga@gmail.com>
Date: Tue, 14 May 2019 20:22:56 -0400
Message-ID: <CAHiu4JM9swU=HeG4kgQUiXFXUSQMZwh_yzOFqmp1dR_sCTunow@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: mud@ietf.org, Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000d806aa0588e228f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/ZzvKaLQTC7Mocd4kcxBvTR-l01A>
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: Wed, 15 May 2019 00:23:36 -0000

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