Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]

[james woodyatt <[e-mail]>]

On Nov 22, 2016, at 11:47, Juliusz Chroboczek <[e-mail]> wrote:
> 
> Assuming you want to allow hole punching, PCP makes sense.

It only makes sense if the distinguished hole punched by the recommendations in Section 3.2.4 IPsec and Internet Key Exchange (IKE) [RFC 6092] are insufficient or unsuitable for the given application.

> Whether you want to allow hole punching in the first place is a separate discussion.

A separate, closely related discussion is whether hole punching should continue to be “opt-in” or if it should be changed to be “opt-out” (assuming it’s even possible to make such a change at this late date, but the roll-out of HOMENET systems might bring an opportunity, should we choose to take it).

I mean, it’s really quite revealing in Section 3.6 in "IPv6 Home Networking Architecture Principles" [RFC7368], which includes a long disquisition about the architecture expressly not taking any opinion on the “opt-in” or “opt-out” question, that the whole discussion gets reduced down to this fairly ambiguous sentence in Section 5.1 of “Home Networking Control Protocol” [RFC7788] to this rather unambiguous positive recommendation for filtering:

>> Accessing internal resources from external interfaces is restricted, i.e., the use of Recommended Simple Security Capabilities in Customer Premises Equipments (CPEs) [RFC6092] is RECOMMENDED.


On Nov 22, 2016, at 08:28, Michael Thomas <[e-mail]> wrote:
> 
> Right. Since Homenet is predicated on ipv6, we should never bake in expectations of doglegging that have their justifications in v4/nat. […]

I think we can safely observe that the expectation for passive listeners on unmanaged home networks to be protected by IPv6 Simple Security from receiving inbound flows from arbitrary hosts on the public Internet is not merely due to the legacy of IPv4/NAT.

During the long and heated debate over RFC 4864 and the even longer and more heated debate over RFC 6092, I would say that the IETF community really did come to the consensus that eliminating the need for NAT to provide address amplification does not entail eliminating the need for simple security at the borders of unmanaged networks. That’s pretty clear in RFC 4864, and we had the opportunity to revisit in RFC 6092, and we did not.

This argument that passive listener protection on unmanaged networks is an obsolescence left over from IPv4/NAT just doesn’t work. We had plenty of opportunities to leave it behind with IPv6 and we quite deliberately kept it. We can’t claim we didn’t know what we were doing.

> There are perfectly good reasons I don't want to hand over control to some dogleg servers […] thankyouverymuch.


And yet, we have the Internet as it has been constructed in the real world according to its deliberately planned architecture, in which most if not all passive listeners on unmanaged residential networks are expected to be protected directly by security packet filters from receiving inbound flows directly from arbitrary initiators over public routes. The architecture instead expressly calls for them to make outbound flows to some exterior service that facilitates their communications or proxies on their behalf at application layers.

That’s your dog-leg. We have it because IETF experts are afraid of the chaos entailed by allowing the riffraff to do without it too easily.

Maybe the IETF community will revisit this architecture in the next version of the Internet Protocol, but with IPv6 I have to say the matter seems well and truly decided at this point. In the meantime, with the Internet we have, it doesn’t make sense to me why we should spend our time specifying protocols for registering names of services in the global domain name system unless we have a realistic usage scenario that shows how they will be reachable directly by arbitrary public hosts.

I just don’t see how there is any such realistic scenario. Hence, I’m not sold that adopting this draft is a good idea.


--james woodyatt <[e-mail]>