[v6ops] draft-palet-ietf-v6ops-he-reporting-00.txt: privacy and other issues

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fri, 21 July 2017 07:06 UTC

DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=VvrYMAmEdivpljWu0Dw1qSqQlrtBhGMA3g9W6yl50sgQ1Mnmg/LssMHlO+sT vsOXlFd6Imo9AZtqCeMqiDJbIcv8WCr/YHYdNUb/uj63J3qShwzVO5TkX XxkzguKwnaRwt19MLgMvBMyWeUiHfH8oq3tIIpjzVXPRzo36oIAg/o=;
User-Agent: Microsoft-MacOutlook/f.24.0.170702
Date: Fri, 21 Jul 2017 09:06:54 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <0DD4D67C-3BD5-4AAD-BC5E-BB3948BD35C0@consulintel.es>
Thread-Topic: draft-palet-ietf-v6ops-he-reporting-00.txt: privacy and other issues
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/i3BWFBVfI2zbkSb_3iwABVM60Fo>
Subject: [v6ops] draft-palet-ietf-v6ops-he-reporting-00.txt: privacy and other issues
Precedence: list

Hi all,

I’ve been thinking about this and talking to other folks, so I will like to get more feedback from the WG.

1) Privacy:
I think just reporting the destination address that fallback to IPv4 because HE2, is enough to provide the operator a signal, so they can consider there is an issue with that path. It may be an operator issue, or maybe somebody in the path or the destination itself. It is up to the local operator to decide if they want to do anything about that or tell the other parties.

If we also keep in the syslog report the origin prefix or address, it looks like there is a privacy issue, however, because we are reporting it to our OWN ISP, he has already that information and much more, and in many cases, they have the obligation to keep such records for months/years, by local regulations.

The privacy issue comes not for keeping that data, but for disclosing it.

In fact, is not true that both, desktop and cellular OSs, do a lot of reporting/telemetry to their makers and even operators? At least I’d that idea in mind, maybe I’m wrong …

2) Implementing in hosts vs CE:
>From my view point, it is much easier to implement a very simple UDP 514 message in HE2, which is detecting the failure and falling back, that asking the host to signal the local CE (or ask the CE somehow to detect it for broken destinations) and ask the CE vendors to provide firmware updates to implement it: It will NOT happen!

3) Alternatives to hosts reporting the failure:
I think was David who suggested “scrape DNS and NAT44 logs”. I’m sure there are other options as well. BUT, this means that the operator need to have “something new” in their network, and what I’m trying to do is to reuse something already available (maybe syslog, maybe something else), so it is a matter not of “installing” something, but just configuring and existing syslog collector with one more address that match the one that we decide to use for it (right now NSP::192.88.99.1).

Toughs?

Regards,
Jordi

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

[v6ops] draft-palet-ietf-v6ops-he-reporting-00.tx… JORDI PALET MARTINEZ