Re: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT)

Tom Henderson <tomhend@u.washington.edu> Sun, 18 September 2016 19:01 UTC

Return-Path: <tomhend@u.washington.edu>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE1E12B14B; Sun, 18 Sep 2016 12:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 sZhU55804Aeh; Sun, 18 Sep 2016 12:01:01 -0700 (PDT)
Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (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 3335112B14D; Sun, 18 Sep 2016 12:01:01 -0700 (PDT)
Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8IJ0N7I003797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2016 12:00:24 -0700
Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u8IJ0IGl018101; Sun, 18 Sep 2016 12:00:18 -0700
Received: from localhost (Unknown UID 17623@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u8IJ0IC7018092; Sun, 18 Sep 2016 12:00:18 -0700
X-Auth-Received: from [73.140.18.44] by hymn04.u.washington.edu via HTTP; Sun, 18 Sep 2016 12:00:18 PDT
Date: Sun, 18 Sep 2016 12:00:18 -0700
From: Tom Henderson <tomhend@u.washington.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <alpine.LRH.2.01.1609181200180.32623@hymn04.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.18.185117
X-PMX-Server: mxout21.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, SINGLE_URI_IN_BODY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NO_MAILTO 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0'
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/1bWN84gQGfkZV37oMYFahPOb9Ec>
Cc: draft-ietf-hip-multihoming@ietf.org, hip-chairs@ietf.org, The IESG <iesg@ietf.org>, hipsec@ietf.org
Subject: Re: [Hipsec] Stephen Farrell's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Sep 2016 19:01:04 -0000

Stephen, thanks for your comments; replies inline below

On 09/14/2016 04:25 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-hip-multihoming-11: No Objection
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - I think section 6 ought note the privacy issue that
> was relatively recently with WebRTC and ICE where a
> client might not want all of it's IP addresses
> exposed, as doing so could expose the fact that the
> client e.g. is using Tor or another VPN service. The
> issue being that in some locations, that information
> may be quite sensitive.  4.2 notes this but in a quite
> opaque way, ("may be held back") but it'd be better to
> say some more. 5.1 is also relevant maybe in that it
> says one "SHOULD avoid" sending info about virtual
> interfaces. Anyway, I think it'd be good to add some
> recognition of this privacy issue to section 6. I am
> not arguing that this draft ought specify the one true
> way to avoid this problem, but only that it be
> recognised.

Your comment led me to review this draft

https://www.ietf.org/id/draft-ietf-rtcweb-ip-handling-01.txt

which I would be inclined to cite, but I am not sure whether it will be put forward for publication soon (and therefore am not sure about citing it).

The below might make a possible summary paragraph to add, however:

"The exposure of all of a host's IP addresses through HIP
 multihoming extensions may raise privacy concerns.  A host
 may be trying to hide its location in some contexts through
 the use of a VPN or other virtual interfaces.  Similar
 privacy issues also arise in other frameworks such as WebRTC
 and are not specific to HIP.  Implementations SHOULD provide
 a mechanism to allow the host administrator to block the 
 exposure of selected addresses or address ranges."

> 
> - 4.11: what's the concern about anti-replay windows?
> I didn't get that fwiw, not sure if that just my
> relative ignorance of HIP or if more needs to be said
> in the document.

It is explained in this sentence:

  "However, the use of different source
   and destination addresses typically leads to different paths, with
   different latencies in the network, and if packets were to arrive via
   an arbitrary destination IP address (or path) for a given SPI, the
   reordering due to different latencies may cause some packets to fall
   outside of the ESP anti-replay window."

Can you suggest changes or do you have a concern with what is stated?

- Tom