Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC

["Fred Baker (fred)" <[e-mail]>]

This is a comment as a participant, not as a chair.

I find myself scratching my head with this, and found myself scratching my head with what became RFC 6092.

My first premise in both cases is that a firewall primarily mitigates attacks on the bandwidth of a network and an aggregated network. An attack that actually hits a host or application will have to be defended against by the host/application or a security service provided by some other device in the network; firewall rules provide a form of defense in depth, but no more. I compare a firewall to the human skin. The skin is, itself, hardly necessary for the "health security" of the body, as the other systems of the body could be active and mitigate attacks on the body. However, it makes active use of those capabilities less of a requirement by preventing certain classes of attacks.

My second premise is that any communication attempt directed to a network, or to a application in a network, that doesn't have a application in the network that willingly communicates with it is an attack.

Now, we have tools - PCP, UPnP - that enable an application to inform the network of its approving presence. If I want someone to be able to connect to a given device using IPsec, when the device comes up, it can inform the network of a n-tuple {application address, IPsec protocol ID, <any>}, and "poke a hole" in a firewall regardless of the description of the firewall. The administration can also log such requests and apply its own policy on whether it honors them. If I want them to initiate SMTP or https connections to a given system, it can similarly announce itself as {address, TCP, port, any, any}, and allow incoming SMTP connections to it.

So regardless of the firewall type, we have tools to enable an application in the network to make itself available to peers "outside". And of course, as suggested in zone-based defenses and in RFC 6092, when a application initiates a connection outside, by implication the firewall can open a "hole" for the return traffic.

So the only protocols, or peers using protocols, under discussion are those that have no application that is willing to have sessions initiated to it from the outside of the network.

RFC 6092 permits IPsec packets as a blanket rule. That facilitates two attacks. First, there is a form of network scanning enabled; a application outside the network can initiate IKE connections to addresses it thinks might exist in the network (observing, for example, email envelope information to find such addresses); if it gets a reply, something is using the address. Second, it can busy out the verification/decrypt unit in a application simply by sending it IPsec traffic that does not have a proper key. That can DOS the application's CPU resources or its communication resources. Now, if a application wants to communicate in that way and recognizes the vulnerability, it can open that hole. But if a application doesn't want to communicate that way (for example, it implements IPsec but the applications it uses have no keys to validate data with), what is the argument for leaving the vulnerability open?

draft-ietf-v6ops-balanced-ipv6-security implements a similar, and much wider, vulnerability. I might well have an http server in my network, but that doesn't imply that all hosts in my network are http servers. Even if many of the hosts in my network are http servers, that doesn't imply that my policy enables access to them from all possible clients. My http server can open a hole for itself, and can be armored to defend it against the many attacks that plague that protocol. My telephones (Cisco 9971 and iPhone 5) are, or can be, http servers as well. Does that mean that my call configuration and history should be available to anyone who wonders about it? Is the presence of one server a reason to expose the many hosts in my network that only operate as clients to HTTP initiated from the outside?

http://www.economist.com/news/science-and-technology/21589383-stung-revelations-ubiquitous-surveillance-and-compromised-software

From my perspective, I think I would prefer that the firewall - if implemented - blocked everything, and applications within the network advised the firewall(s) of traffic that they are willing to receive. If a potential session has no willing counterpart within my network, I don't see the argument for letting the first packet in.