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

[Erik Kline <[e-mail]>]

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 <[e-mail]> wrote:
>
>
> Lorenzo Colitti wrote:
>
> On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>