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

[Fernando Gont]

---------- Forwarded message ----------
From: "Fred Baker (fred)" <fred at cisco.com>
Date: Nov 12, 2013 1:54 PM
Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
To: "v6ops at ietf.org WG" <v6ops at ietf.org>
Cc:

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.

_______________________________________________
v6ops mailing list
v6ops at ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20131113/e329378d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 202 bytes
Desc: not available
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20131113/e329378d/attachment.sig>