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
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> - 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

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

Hipsec mailing list

Reply via email to