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

[Ray Hunter <[e-mail]>]

Lorenzo Colitti wrote:
> On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) <[e-mail] 
> <mailto:[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,