[DNSOP] TA signal - suggestion to enhance signal

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 13 May 2019 03:17 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0D328120135 for <dnsop@ietfa.amsl.com>; Sun, 12 May 2019 20:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uuS_9QLT9cWi for <dnsop@ietfa.amsl.com>; Sun, 12 May 2019 20:17:49 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 C79C412011F for <dnsop@ietf.org>; Sun, 12 May 2019 20:17:49 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id o7so13142295qtp.4 for <dnsop@ietf.org>; Sun, 12 May 2019 20:17:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FryQol6glsPm8rhSWvVvivj26xP9UXDutoo7FmARB0Y=; b=X4W6DT6bodlFrGSsUNaKpWkd+2awCL2HKXTfHkhOZ9CEHTWBG65j6U7/MGx3md/mjJ elik77/hxfIb/75CDXR6KsjSTnGJGMW4FEXe+HgW5VijKTHWAnao4wEEhJVmjF6h4yM5 NJAQGg5PGv9lvan+DZq8miW88NF3BVRwduPTaL1GYUYixxk2RTOHMYCveneC23cb+jIO 999vuM3T5RHn65lLgky+u01O47wLiQezVfCQKEfsj7mf3Qz7Znm3R1K9adiyQnWuGgER Aawijua5ApcuvvaGtzs3pKwNWfHaS9b2+mPp56dtQhWTFHsLsa69gUGhKrSf4F91Mgnq JNAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FryQol6glsPm8rhSWvVvivj26xP9UXDutoo7FmARB0Y=; b=F3DXOHPBDJNYNG4tc4NHfvez6/zIZa71aefcBDMhpiGzdrAN2uZynL1yWasachuQ+c myefrfARrm3iLTttYDtnGrE0ONSZe3Zb8WjmdCGON0BEUYp9cKEv4yoFfCmQRjIqrBDM eNfSnYRN24sCNfHIDYHzPmdh/exs3elVcCwd5dSSVnbgVQ6BobpmDanglh7VPzhqumEQ KDkwtV9av3zpcLhD1R+s+RP4ypOzJUatVV5JABChWkyyuWthVUQd3JdPYUdbs8766JYI OA8uY5pDMkerkJej5Ux5+0F5lirwTkSshuxc2Rq+Cw8XptWdbvxR4ZG+U1W52+ytHIXu HsDA==
X-Gm-Message-State: APjAAAXUSzm9FNWj8azpV4auHzRK98CNNmmofgs+Nj/7TqSpmhymEcje 60rIOnLqe7lZ2MGBmQWbfGxcRqX8XLTow3kYRkxOS/u4
X-Google-Smtp-Source: APXvYqwEehvWR+gXRaCRNlQwDK5iTmg9BGhnaiHzxcQWRypQivqj79GmtN8khyKhqA+dzV4ErQLAKcHvrePNSuSv8FM=
X-Received: by 2002:aed:237b:: with SMTP id i56mr3980699qtc.370.1557717468548; Sun, 12 May 2019 20:17:48 -0700 (PDT)
MIME-Version: 1.0
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 13 May 2019 10:17:36 +0700
Message-ID: <CAH1iCip8CQbU4wSCoG410fAUB88cvAtC=SHqGRB0GAwZdakiEw@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005f908b0588bc5c65"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8HDvjXBT_80uVE-zIVsCghOJGEs>
Subject: [DNSOP] TA signal - suggestion to enhance signal
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2019 03:17:52 -0000

The original RFC 8145 gives the ability to gather trust anchor signal data.

There are limitations related to inferring either reasons for behavior
observed on the aggregate volumes, or identifying originating
resolvers/forwarders versus upstream resolvers/forwarders (which could
include both NAT and forwarder root causes).

I believe the additional information that would be operationally useful as
well as helpful for being able filter or otherwise drill down within the
collected data.

The extra information I believe would be useful includes software (package
and version), and some unique identifier for each host, plus an identifier
derived from (possibly non-unique due to RFC 1918) host's IP address.

Putting this information underneath the _ta-* label, would allow the
high-level signal (the _ta itself) to be aggregated as easily as currently,
while also enable drilling down and/or aggregating/filtering to address any
PII issues.

Suggestion for software id: whatever software currently puts into
version.bind or equivalent name, in the CH TXT class and type.

Suggestion for host id: some UUID generated either at software install
time, or at software launch time,

Suggestion for IP-based ID: hash of IP, where  IP is "live", so changing
the IP results in change to the hash. This has the added benefit of
validating that the IP address of the incoming _ta query is the originating
system, versus NAT IP (possibly folding multiple hosts onto fewer/different
IP addresses) or forwarders who forward queries for clients.

I believe these will be useful in analyzing the 8145 data, to extract
better signal data, and to filter data that is effectively "noise", and/or
track sources and changes better across event boundaries.