[sacm] SWIMA and Source Identification

"Schmidt, Charles M." <cmschmidt@mitre.org> Wed, 18 January 2017 17:47 UTC

Return-Path: <cmschmidt@mitre.org>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB201294C8 for <sacm@ietfa.amsl.com>; Wed, 18 Jan 2017 09:47:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.399
X-Spam-Level:
X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.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 GzslMvtpQDvl for <sacm@ietfa.amsl.com>; Wed, 18 Jan 2017 09:47:04 -0800 (PST)
Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 051411294EF for <sacm@ietf.org>; Wed, 18 Jan 2017 09:47:03 -0800 (PST)
Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2970E6DCA69 for <sacm@ietf.org>; Wed, 18 Jan 2017 12:47:03 -0500 (EST)
Received: from imshyb01.MITRE.ORG (imshyb01.mitre.org [129.83.29.2]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 1C9D06DCA68 for <sacm@ietf.org>; Wed, 18 Jan 2017 12:47:03 -0500 (EST)
Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 18 Jan 2017 12:47:02 -0500
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Wed, 18 Jan 2017 12:47:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Am4MdbPWaL+ckd03+t28TLDjSBFfmI/lX5kJQ34BEOQ=; b=UZTOq5QPudiGDnk8NzQ+KQd+VIPAmS3b4Pbxv8izhEmYA0OBZh55SGFSqQy8QwTMMjPwlJ5ijElDI7sEokF6Xc85/EJVIdmOt0+Xt4F9Y4fUDtpadYon9zZmV2tU1/AGhJ79aunYYqwGWrLa9zTxY6T+UqltKvJd738FlQzvSSk=
Received: from CY1PR09MB0889.namprd09.prod.outlook.com (10.163.43.27) by CY1PR09MB0889.namprd09.prod.outlook.com (10.163.43.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 18 Jan 2017 17:47:01 +0000
Received: from CY1PR09MB0889.namprd09.prod.outlook.com ([10.163.43.27]) by CY1PR09MB0889.namprd09.prod.outlook.com ([10.163.43.27]) with mapi id 15.01.0860.012; Wed, 18 Jan 2017 17:47:01 +0000
From: "Schmidt, Charles M." <cmschmidt@mitre.org>
To: "<sacm@ietf.org>" <sacm@ietf.org>
Thread-Topic: SWIMA and Source Identification
Thread-Index: AdJxp5sYHe/x5LkYTHmlxfLVFL5jpQ==
Date: Wed, 18 Jan 2017 17:47:01 +0000
Message-ID: <CY1PR09MB0889773405E7187F1F15EE86AB7F0@CY1PR09MB0889.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cmschmidt@mitre.org;
x-originating-ip: [192.160.51.88]
x-ms-office365-filtering-correlation-id: 2768462b-8fd9-4d07-5b44-08d43fca01cb
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0889;
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0889; 7:CvU88cV+BkhSCNoU0WX0aXC3qucnxdTda8JMKXuW0EJis1W9lJPzUnbMIHVqpV3tNgSI+ACRikAitlV5y7bCd1Yj7E+CqB5/2trqvoYW0NtvAikNDCDbO1yYzmJDs/v3QLqctpvQqrJARComRAtGbjIsIFHPKpTOcnANCu0k++gxmpSIFeose/jy0mJWGJCvlZrplRUBgFRePuhj205bh4Nl4L5Pxa0DXcwi/L3tvc0Fraiq11m3ohGlJGvNS47FuMb86+tQNXyoycuDfdxXi0hspqSImcsl7gaqRqVVTPSdj3w4oLhGvhOx9vpzVhJ+NBTQK+w+hLYTorDcuXWaGAD/88Ygsvv0zfyAh3ENZ5oEdn3cumaQ9e06fErQCQcQ9IoNAcUmkyYHcR5hbqpSmVzBmXmOP5RFkAndRg0P9ET9OkpPim1LdY/3LjymOGmThiFVp7rbELkfMb2n/cB8aQ==
x-microsoft-antispam-prvs: <CY1PR09MB0889BAFCB5D664161BB50765AB7F0@CY1PR09MB0889.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR09MB0889; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0889;
x-forefront-prvs: 01917B1794
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(7916002)(39410400002)(39840400002)(39450400003)(39850400002)(39860400002)(189002)(53754006)(199003)(6506006)(77096006)(25786008)(105586002)(6436002)(99286003)(81166006)(106356001)(102836003)(122556002)(6116002)(38730400001)(2900100001)(189998001)(55016002)(3660700001)(3846002)(3480700004)(50986999)(81156014)(8936002)(7696004)(54356999)(8676002)(5660300001)(86362001)(101416001)(97736004)(66066001)(33656002)(110136003)(92566002)(107886002)(68736007)(6306002)(9686003)(74316002)(450100001)(3280700002)(2906002)(53936002)(7736002)(305945005)(491001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0889; H:CY1PR09MB0889.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 17:47:01.0529 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0889
X-OriginatorOrg: mitre.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/ZbXuWqbcPz7xh6C_9gGTqnTKkEE>
Subject: [sacm] SWIMA and Source Identification
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 17:47:07 -0000

Hello all,

In last week's virtual interim meeting we had a long discussion about the new draft's handling of source identification. No final resolution was achieved on the call so let's see if the list offers some clarity. References to the current draft are to draft-ietf-sacm-nea-swid-patnc-00 (https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swid-patnc/). References to issue numbers are from the Software Identification GitHub tracker (https://github.com/sacmwg/software-identification).

On the call we talked about two ways to handle software identification: the procedures described in section 3.4.5 of the new draft, and a variation proposed by Dave Waltermire:

Procedure in the current draft:
Each record and record identifier is accompanied by a 1-bit Source First Use flag and a 7-bit Source Identification Number field. Whenever a Collector gets information from a new source, it assigns that source a 7-bit Source Identification Number. The first time records from that source are sent to a given Validator, the Collector sets the Source First Use flag in all records from that source in the given attribute. In all cases, records/identifiers are always sent with the Source Identification Number the Collector assigned to the source from which each record/identifier came.

Dave Waltermire variation:
There is no Source First Use flag and the Source Identification Number field is 8-bits. Collectors assign Source Identification Numbers to each source as defined above. No special flag is used to indicate first use of a source to a Validator and Validators can note a new source simply by observing the use of a Source Identification Number it has not seen before. (Personally, I agree with Dave's observation that the Source First Use flag adds complexity without really adding much value.)
In addition, there is a new attribute exchange by which the Collector can send a text string describing each source. Basically, this would provide the collector a way to assign some descriptive information to each Source Identification Number. The contents of this string are not currently standardized.

In addition, there was a question regarding the "lifetime" of Source Identification Numbers. Two valid options were noted, in order of likely duration:
- Session (as defined by the valid lifetime of a Connection ID value in a PB-TNC session) - This is the same lifetime of a subscription established by a Validator to a Collector by which the Collector pushes new information based on detected changes. The possible disadvantage is that there are many reasons to terminate a session (including a desire to free up resources and the fact that the PB-TNC state machine does not allow certain actors to do things in certain states, and if the Validator needs to take one of those actions, their only choice is to close the session and start a new one - see RFC 5793 PB-TNC, section 3.2). This could mean that the Validator might be unable to correlate sources across messages separated by only a few hours (current procedure) or need to re-collect descriptive information about sources fairly regularly (Waltermire variation).
- Event ID Epoch - The Event ID Epoch is conveyed in every attribute that sends records or record identifiers. It is used to indicate continuity in the total ordering of Event Identifiers. An Epoch can remain constant across multiple reboots of a Collector. This provides better long-term consistency in Software Identifier Values than Session lifespans. A possible disadvantage is that Epochs are intended to be very long lived and it is possible that the 256 available Source Identifier Numbers could be exhausted before an Epoch changes, although this would only happen if the Collector had a very large number of sources (~3 is probably more normal) and the Collector loses track of sources regularly so needs to re-assign new values to old sources repeatedly (probably an unlikely situation).

So the question to the group (phrases as a yes/no question so that "+1" can be a valid response):

1) Do people like the Waltermire variation for Source Identification capabilities described above?

2) Do people like using Event ID Epochs for the lifetime of Source Identification Number assignments?

Thanks,
Charles