Re: [DNSOP] TA signal - suggestion to enhance signal

"Wessels, Duane" <dwessels@verisign.com> Mon, 13 May 2019 04:21 UTC

Return-Path: <dwessels@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67B7120043 for <dnsop@ietfa.amsl.com>; Sun, 12 May 2019 21:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 iq4T5G0zIBFN for <dnsop@ietfa.amsl.com>; Sun, 12 May 2019 21:21:44 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AD812002E for <dnsop@ietf.org>; Sun, 12 May 2019 21:21:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9069; q=dns/txt; s=VRSN; t=1557721304; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=3tHaCXmrAD95o4LSexRxogZLIvJoWlrom1K9bv9trug=; b=m4BaIRIlzmvzJ0emi7S9E5mqSEI0djmTGlMyahUkzzniX2h4CgH5LveK 5Tdnb4xwDpGhDxKgTzD6rd0wff58OI48yirj0Ys6oTIPr69nNpyNhDWk6 ctI7qDoDoorkN2vfUUx1Aa9yFRI1CQSRML6ohE5WLy09kKwD7n5/76MAW SUPw5ihwVJXiSbRjm0yB1tPIq6zHiyD0EnqOFvdS49L9kQEkvEPwAGVkS Lu0Us21COVlSEX6AWtKmiy3hLXb8a2fmuo91tfUGgyHMxfL477f+YPS1d JwK9RyJaXik1F0kZuBj+7ByGwtadCxHIGUh2XaEFOnKMsH5V5nvnKRrSK Q==;
X-IronPort-AV: E=Sophos; i="5.60,464,1549929600"; d="p7s'?scan'208"; a="7738132"
IronPort-PHdr: 9a23:RJwNgBeHtiAN3K2xwfpyK+ZglGMj4u6mDksu8pMizoh2WeGdxcW8YB7h7PlgxGXEQZ/co6odzbaP6uaxAidfsN6oizMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vMRm6twHcu8cZjYZgLqs61wfErGZPd+lK321jOEidnwz75se+/Z5j9zpftvc8/MNeUqv0Yro1Q6VAADspL2466svrtQLeTQSU/XsTTn8WkhtTDAfb6hzxQ4r8vTH7tup53ymaINH2QLUpUjms86tnVBnlgzocOjUn7G/YlNB/jKNDoBKguRN/xZLUYJqIP/Z6Z6/RYM8WSXZEUstXSidPAJ6zb5EXAuQBI+hWspX9qVUNoxuwBwasBf/gxTBTi3/5waE61v4sHR3a0AA+Gd8FrXTarM/yNKcXSe25wqnHwivYb/NNxzj97JPIfgg8qv+CQLJ/a8zRxlchGwjYiViftILkMC2O1uQWrWeb6/FgWPmxi2E5sQFxoyOvxsYjionPnI4a1lfE9SBgzYszONa2S1Z7bMa5HJdMrS2WKol7T804T211uCs3xKcKtJG4cSQS1Zgr2wTTZ+GFfoSU+B7vSemcLDRiiH54e7+znxiy/lajx+HgU8S51UxFoylBn9bXs30A2QLf5dWGR/Z45Uis3TeC2gLW5+xKL005l7fUJpg8ybAqjJUTq17MHirulUXzi6+Za1sr9/Cz6+TifrXmvpicN5Joig3mMqQhhMi/AeMgPwUTQ2aV4fmw273780P2QbpGkuA6nrPHsJ/GIsQbvLa5DxVP3Yk+8Rq/ES2m0M8enXUdMF1FfxeHg5DoO1HIPv/4Ee+yj0mwnDtx2vzLPLPsDo/QInXDnrrtZ7lw5k1ExAo2199f5pZUCr8bIPL0X0/8rMHXDxEnPAyv2OboFtF91pgFVGKRHKCZKqLSsUSJ5uIgJemAfpMauDH4K/Q9/f7hkWc5mUMBfamuxZYYc2q4HvV8LEWfe3bsmskOEXsUsQokVuDllVyCXiJQZ3apWKI84Co2CI2jDYjZR4CthKaN0zu8Hp1TfmpGEEyDEW/0d4WYXPcBcD+dIsl6kjwDTbisUI4h2g+ytA/00bZnKfDU+iJL/a7kgfJv5uTV3T0z/j9vCMLVh2uXTmhy2HsFWzIsmqx+qk9mzVGr3q1xgvgeHttWsaBnSAA/YNTjwvdhBtTpHkrtY96PRRzuFtm5DCoqQ9Yq68EDeUdmGtqkyBvE2nz5UPcui7WXCclsoern1H/rKpM4ki6e2Q==
X-IPAS-Result: A2EXAACE8Nhc/zCZrQpkGwEBAQEDAQEBBwMBAQGBUwQBAQELAYFmgj8KmSSDXoVhjxSBewkBAQEBAQEBAQEDBAEvAQGBS4J1AoIxNgcOAQMBAQEEAQEBAQMBAQECgRGCOikBgmcBAQEBAgF5BQsCAQgYLgIfESUCBA4FDoJJSwGBagMOrBGFR4IyDYITEIEzAYFOiheBQT6BEScfgkw+ghqFZoImBItOhn2UUTkDBgKCCYMKghWJZ4NxlWyDdZBhjGICBAIEBQIVgVYIggFwFWUBgkGCGgEXjh9yAY1zK4EEgSEBAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 13 May 2019 00:21:31 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1713.004; Mon, 13 May 2019 00:21:31 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
CC: "dnsop@ietf.org WG" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] TA signal - suggestion to enhance signal
Thread-Index: AQHVCTqBg+uTpFe1V0aS7HvMPj1IV6Zot0YA
Date: Mon, 13 May 2019 04:21:31 +0000
Message-ID: <865BAD7D-3ED3-4E91-8FD0-93FBA1F8B4C5@verisign.com>
References: <CAH1iCip8CQbU4wSCoG410fAUB88cvAtC=SHqGRB0GAwZdakiEw@mail.gmail.com>
In-Reply-To: <CAH1iCip8CQbU4wSCoG410fAUB88cvAtC=SHqGRB0GAwZdakiEw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_43A39A40-324C-4D7D-8371-D638097C251C"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/utBMowAACLzfLX2_wV-aPov42Co>
Subject: Re: [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 04:21:46 -0000


> On May 13, 2019, at 10:17 AM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
> 
> 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.
> 
> Thoughts?


Hi Brian,

Thanks for the suggestions.  I think the first discussion needs to be whether there is support for better signals at the expense of possibly less privacy.  My sense of the way things are today is that "privacy is king."  


DW