Re: [mile] Ambiguity when NodeRole@attacktype is used

Option iii seems reasonable.
If we have consensus on this I will update the guidance draft.

Panos

-----Original Message-----
From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Roman D. Danyliw
Sent: Sunday, July 28, 2013 10:09 AM
To: mile@ietf.org
Subject: [mile] Ambiguity when NodeRole@attacktype is used

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
_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile