To fairly analyze security impact by DPF on organizations using private network and/or firewall, we need to consider for what purposes organizations use firewalls/NATs and which of them are broken by DPF.
- IPv4 address shortage & easy network management
- Address concealment
- Block inbound connections
- Outbound connections are inherently securer than inbound ones
- Management can keep employees from running undesirable services
- Unprepared servers can be protected from attacks
- Block outbound connections
- IDS & Logging
One of the most important reasons to use private networks is because IPv4 addresses are being sold out and private networks make network management easy. Obviously DPF has no adversary effect on this goal. In the light of this goal, inbound connections being blocked is a side-effect. DPF removes this undesirable side-effect.
Private network is considered somewhat secure because the addresses of hosts are hidden from outside. In DPF, private addresses are still hidden from the public network.
Organizations block inbound connections for many reasons. I believe that the followings are major reasons:
Outbound connections are generally considered securer than inbound ones because the former is more difficult to attack than the latter and because some attacks are only possible for servers. To attack a client, the bugler generally does IP spoofing and packet hijacking. On the other hand, some attacks toward servers can be easily done by IP spoofing alone. SYN-flooding is a popular example. Since DPF invites inbound connections by opening pinholes at the firewall/NAT, DPF does not have this goal unbroken.
By blocking inbound connections to arbitrary addresses, an organization can keep members from running undesirable or insecure services. If DPF inagent used a strong authentication/authorization of server applications that send DPF commands, then it would have easily support this goal. Unfortunately, current version of DPF does not use a secure communication for DPF command exchange. DPF inagent, however, can be instructed to accept commands only from a specific network interface. Therefore, if a network can be partitioned into trusted and untrusted one, then the goal can be achieved by setting the inagent to accept DPF commands only from the trusted network.
Maybe this is the biggest reason that organizations block inbound connections. Unlike clients, servers are generally wide-open to any client. There are many legacy servers not well prepared to attacks. By blocking inbound connections, those servers are protected from attacks launched outside the private or firewalled network.
Definitely DPF makes servers accessible from outside and this can introduce security problems. However, we must understand that there are two contending interests. One is to protect nodes from attacks by closing the door and the other is to collaborate with the world by opening the door. If an organization can sacrifice one for the other, the solution is easy. However, in most cases one goal must be achieved with the other sacrificed as little as possible.
DPF is a decent solution of this optimization problem. DPF opens the firewall/NAT only as much and as long as required. DPF invites inbound communications toward an address only if there is a DPFnized server listening on the address. Compare this to the general practice of manually opening firewall/NAT for a range of addresses. It is generally impossible to know in advance how long and what addresses a server will listen on. Therefore, administrator must open much more addresses than necessary and for much longer period. These extra opening can be exploited by buglers to attack innocent servers.
Outbound connections are blocked, though not common as inbound cases, for similar reasons. Since DPF assumes that outbound connections are allowed, you cannot use DPF if the security policy of your network is so strict that this assumption is not true. However, if a network can be partitioned as explained above, then this goal can also be achieved.
Firewall/NAT provides a chokepoint of network flow so that other protection systems such as anti-virus, logging, and Intrusion Detection System (IDS) can easily be placed. In DPF, every communication with outside (including DPF inagent) occurs through the firewall/NAT. Thus it has no effect on this goal.