[hiaps] with respect to the BOF request.

joel jaeggli <joelja@bogus.com> Thu, 12 December 2013 08:31 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: hiaps@ietfa.amsl.com
Delivered-To: hiaps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169FC1ADF51 for <hiaps@ietfa.amsl.com>; Thu, 12 Dec 2013 00:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 aJu2pr_Y8R-g for <hiaps@ietfa.amsl.com>; Thu, 12 Dec 2013 00:31:46 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6A21AD68D for <hiaps@ietf.org>; Thu, 12 Dec 2013 00:31:46 -0800 (PST)
Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id rBC8Vd0q007052 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <hiaps@ietf.org>; Thu, 12 Dec 2013 08:31:40 GMT (envelope-from joelja@bogus.com)
Message-ID: <52A97466.2060901@bogus.com>
Date: Thu, 12 Dec 2013 00:31:34 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Thunderbird/26.0
MIME-Version: 1.0
To: hiaps@ietf.org
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HVVGFWtpf1QRefbH7kcauTCT2xjhFw6Xl"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 12 Dec 2013 08:31:40 +0000 (UTC)
Subject: [hiaps] with respect to the BOF request.
X-BeenThere: hiaps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" <hiaps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hiaps>, <mailto:hiaps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hiaps/>
List-Post: <mailto:hiaps@ietf.org>
List-Help: <mailto:hiaps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hiaps>, <mailto:hiaps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 08:31:48 -0000

>Description: Host identification is required in IPv4 when the hosts are
behind a NAT box or
>when the communication is tunneled such as using IPSec. Host
identification is also
>required in IPv6 when the hosts are assigned addresses from a shared
prefix. In most of
>these scenarios, the hosts access the network using Wireless Local Area
Networks, aka
>Wi-Fi access. In case the hosts are behind a NAT box, there is a strong
need for the host
>identification when the host is accessing a fixed network and trying to
place an emergency >call.

It is likely given current events, that persistent identifiers visible
to on-path observers are going to be viewed by the IETF community in
general in an extraordinarily negative light. in particular in the IPv6
context I would think it antithetical to the goals of regular rotation
of temporary/privacy or cryptographically generated addresses to retain
host identity bindings that are visible outside a limited scope e.g. an
l2 domain and which persist across host address changes.

In terms of employing them for roaming, the question of how would they
be generated and where who they be stored becomes germain. What
semantics are they actually carrying and the question of persistence
further raises the  stakes with respect to revalation to remote observers.