[mile] Ambiguity when NodeRole@attacktype is used

"Roman D. Danyliw" <rdd@cert.org> Sun, 28 July 2013 14:09 UTC

Return-Path: <rdd@cert.org>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C547F21F9C4A for <mile@ietfa.amsl.com>; Sun, 28 Jul 2013 07:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.185
X-Spam-Level:
X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elBIAvg4QG-V for <mile@ietfa.amsl.com>; Sun, 28 Jul 2013 07:09:25 -0700 (PDT)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2140C21F9C5A for <mile@ietf.org>; Sun, 28 Jul 2013 07:09:25 -0700 (PDT)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r6SE9OSp018602 for <mile@ietf.org>; Sun, 28 Jul 2013 10:09:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1375020564; bh=NJEMy8/trAt/BjtA+GKUkWQKfJ6xf7gPvz85N/yxMZE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=Pa9UROW5/yqxWGRo2v7T//YrOFkl7Jtw/ma5swJIr0y+xVyGRXWyBmxSyc7TaXGR2 pnF58v9wHRnofwyGfnpGxTM45CKxjQPJ5lxy65FgM/ilEY3Wjn4gRJmja4EaTiOvUs iuEXE2Le7FFNIycuw/5e5M6/35WaRESbXutuRdy0=
Received: from CASCADE.ad.sei.cmu.edu (cascade.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id r6SE9ONC023871 for <mile@ietf.org>; Sun, 28 Jul 2013 10:09:24 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 10:09:24 -0400
From: "Roman D. Danyliw" <rdd@cert.org>
To: "mile@ietf.org" <mile@ietf.org>
Thread-Topic: Ambiguity when NodeRole@attacktype is used
Thread-Index: Ac6Ll10RNniDIZrkT/SDj+FcMbo0jA==
Date: Sun, 28 Jul 2013 14:09:23 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC13C55958@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [mile] Ambiguity when NodeRole@attacktype is used
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mile>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jul 2013 14:09:29 -0000

NodeRole has two attributes: @category (from RFC5070) to describe the legitimate purpose of the system; and @attacktype (added in the -00 draft using a modified list from FraudType in RFC5901) to describe attacker usage of a system.  The following three situations might arise in the current definition:

(a) legitimate purpose of the host is known (@category set), attacker's use of the system is unknown or not applicable (@attacktype not set)
(b) legitimate purpose of the host is known (@category set), attacker's use of the system is known (@attacktype set)
(c) legitimate purpose of the host is unknown (@category not set), only the attacker's use of the system known (@attacktype set)

A few questions when considering these situations.

(1) Given the current definition of cardinality, @category is required but @attacktype is optional.  What should be the value of @category in situation (c)?

(2) Multiple NodeRole elements can be used to express different roles.  For example:

1: <Node> 
2:  ... 
3:   <NodeRole category="www" /> 
4:   <NodeRole category="database" /> 
5:  ... 
6: </Node>

In the case of situation (b), where one wanted to convey that the system was also used as a 'c2-server' in addition to the two legtimate roles it has as a "www" and "database" server, in which NodeRole (Line 3 or 4) should the @attacktype be set?

Possible solutions include:

(i) Merge @attacktype into @category, perhaps which a prefix of "attack-".  With this approach, neither (1) or (2) can arise.

(ii) Add an "unknown" or another escape value to @category which would allow a for an @attacktype to be set even when legitimate use of the system isn't known (or doesn't exist).  Tell implementers that when multiple NodeRole elements are encountered but one some have @attacktype set, its positioning isn't significant.

(iii) Same guidance to implementers as (ii) but make @category optional (so now the escape value is not required).

Roman