Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

Erik Kline <ek@google.com> Tue, 07 July 2015 12:59 UTC

Return-Path: <ek@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08C1A034F for <v6ops@ietfa.amsl.com>; Tue, 7 Jul 2015 05:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 tVj8qjpnlqJS for <v6ops@ietfa.amsl.com>; Tue, 7 Jul 2015 05:58:58 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C9F1A02F1 for <v6ops@ietf.org>; Tue, 7 Jul 2015 05:58:57 -0700 (PDT)
Received: by wgjx7 with SMTP id x7so167160178wgj.2 for <v6ops@ietf.org>; Tue, 07 Jul 2015 05:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cuMac06x+RZRc1nauDJXDKeUf+2ohMhOGIGAJ4iGYaA=; b=VuH/anHFaxWUM2ZjxhV2eXBNKElfXTTW/JxpYOtCAC443kwd77pvy5N2L+MZGNaEdc gK+d7gEUYwyurk1Qdx7EM6PlJGueRRlVIiOHReL0HgtRBI0Aei2OLklf8m0dRMdWN60V uKKN6Ccmmjju2OMDEA5ShisgS4POEBY5GO576QSGgWnTMqZbGiL7KuDGd15cLN9cqo7y 4DGSJaryXDuuDOPxUWnMuRc48i53NU/22+AL2xILZm3U7e4Y1WFLf8L/46hYRUA1Ax9F d4GyLaq/zYAoWAkPf1Es4pmzBKojUD8eSd5nIXr77ZAXeaL+Xp7OleapJDfwogPEILGK ws8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cuMac06x+RZRc1nauDJXDKeUf+2ohMhOGIGAJ4iGYaA=; b=dcGX/IRgWHbeeOx2hOifLoWsC4To2m3STW/a3uBL9RaD+zcls0milvM8Os9NSYM8F2 I2S7s9Xdm5/jf0AEuyiKx0qeiOfR/yTF7nD3F2p6BpZ5hhG13xcSCWRvpfxGdftzeRCu JqlP9znlVpl1fZ65mfc3oRUKo1acs63D+bgzoSugkSq42tENb/LxLptAeMQLwJVAOT3M DzWDjS32u32YLVTZjLCOT+t0OUysr1Hlpjhbxnl+OVlTZvmzzKFmaiTcTwEi94tvuSRG vihrr1TcQrG+RTwTUeTtFzFoN+zDOrDpwpxmRrQczjzkQQrf8uPzdlSoemZYf0loryEQ wiDg==
X-Gm-Message-State: ALoCoQnA1F9+EDX9t3SxqyfxFE/udPdL6R0D+z1RUyuFm+tMaYTea69iSxxVTrvRE7kOncsZN3VX
X-Received: by 10.180.85.194 with SMTP id j2mr8024590wiz.11.1436273936559; Tue, 07 Jul 2015 05:58:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.138.203 with HTTP; Tue, 7 Jul 2015 05:58:36 -0700 (PDT)
In-Reply-To: <559BCACB.3000106@globis.net>
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <CAKD1Yr07M6mXtbL=ewpL7daR4MdvB7fJ_Vu1tyDvmQkzM6zN0w@mail.gmail.com> <559BCACB.3000106@globis.net>
From: Erik Kline <ek@google.com>
Date: Tue, 7 Jul 2015 21:58:36 +0900
Message-ID: <CAAedzxoeurLMLuUm_WHNe4kLp-1QZyQs94AgTgAgaSYAJyQN3A@mail.gmail.com>
To: Ray Hunter <v6ops@globis.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/KRWyVcioI9250mokcC-njsTKuO0>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" <draft-colitti-v6ops-host-addr-availability@tools.ietf.org>
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2015 12:59:00 -0000

I think it's solvable with the logging I mentioned in an earlier post.

Certainly when Google built such a system internally it seems to have
kept the audit folks happy.

On 7 July 2015 at 21:49, Ray Hunter <v6ops@globis.net>; wrote:
>
>
> Lorenzo Colitti wrote:
>
> On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) <fred@cisco.com>; wrote:
>>
>> The statement that I don't see in the document, which would help me
>> personally, is a problem statement. I would guess that the problem statement
>> is "we think some networks are limiting host interfaces to a single IPv6
>> address." I'd want a little more detail, but I'll bet that's the crux of it.
>
>
> Not necessarily "are limiting" today, but "will limit" in the future.
>
> Suppose that all operating systems of interest to a given network support
> DHCPv6 and it is thus possible to run a network without SLAAC and without
> IPv4 without denying service to substantial percentages of users.
>
> Let's consider what would happen in such a DHCPv6-only network. How many
> addresses would be available to each host? Because DHCPv6 requires an
> explicit request to the network before an address can be used, the answer
> is, by definition, "as many as the network administrators decide to make
> available".
>
> In some of these networks, the "as many as the network administrators
> decided to make available" may equate to just one. There could be lots of
> reasons for this: technical reasons such as "our IPAM and logging systems
> support only one address per host and it's tied into our legal intercept
> system so we can only give out one address per host", "we only have enough
> TCAM entries for one address per host", "one address per host is what we do
> in IPv4, and we want to be consistent with that".
>
> If that sounds unreasonable, now consider what would happen in a hotel
> network that charges $5 per device. How many addresses would be available to
> hosts on such a network? At best, one for every $5 paid. More likely, if the
> billing system does not support more than one IPv6 address (why would it?),
> the answer would become "one per MAC address".
>
> I hope we agree that such networks provide suboptimal service, and that
> there are a number of things that users would like to do that require either
> the availability of more than one IPv6 address.
>
> If we are able to agree on that, then it is a useful statement to make, for
> two reasons:
> 1. The network administrators might listen to the statement.
> 2. Client and server implementations can implement network configuration
> protocols such as DHCPv6 in a way that does not lead to this suboptimal
> scenario.
>
> Cheers,
> Lorenzo
>
>
> If I might add some comment to the "problem statement"
>
> I'd like apps and users to be able to enjoy privacy from the "bad guys", and
> also be shielded from general attack and casual scans.
>
> However, I'd also like the "good guys" to be able to track security
> relationships at some abstract level for audit and security purposes.
>
>
>
> IMVHO That's still very much an area of "work to be completed" and is also
> the main reason why network operators want to limit the addresses in use
> (rather than the $5 per address reason cited).
>
> As an example, inbound sessions can be clearly directed to a particular
> stable/well known destination address e.g. using DNS. And application
> daemons can generally be configured to listen only on particular addresses.
> But has anyone tried to force apps to use a particular source address as a
> source for related sessions, or "mirror at L7" outbound sessions to use the
> same source address as the destination address of the inbound message?
>
> In OSI speak that's the session layer, and we don't really have one.
>
> So the problem isn't just a matter of supporting multiple addresses at the
> network adapter layer; it's a matter of how those addresses are bound to
> apps, and how/when they are selected.
>
> As one example, I recently came across an app that bound quite happily to a
> particular address on a VM adapter for inbound sessions/messages, but
> defaulted to using the first address configured on the underlying VM for all
> outbound sessions (rendering any stateful firewall pretty much useless,
> because the 1st underlying address was at the mercy of the cloud operator,
> who could shift load around between physical machines at will).
>
> As another example, I've also come across plenty of firewalls or proxies
> that use NTLM or some other L7 protocol to identify a "user", but are then
> stuck to IP authentication for further follow up sessions, because NTLM or
> equivalent mechanism is either too slow, or not supported on that particular
> app.
>
> You also have the "https first" problem. In some cases/countries it is
> illegal to intercept/break https encryption (e.g. using fake certs). So if a
> user first connects to a proxy for a site that uses https, there's no way of
> authenticating them, and they are blocked until they use a standard http
> session (to another site).
>
> In short: Is there any intention to include a shim (containing some sort of
> nonce) to allow (legitimate) tracking and authentication (within an AS)?
> equivalent of http cookie at the network layer?
>
> That could even be stripped when leaving an AS/site boundary to alleviate
> privacy concerns.
>
> Or at least some more clarification on socket binding?
>
> I fear that this isn't as trivial a problem as the draft seems to suggest.
>
> regards,
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>