[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tunnel protocols (draft-ietf-v6ops-cpe-simple-security-03)
On Sep 1, 2008, at 14:37, Mark Smith wrote:
[...]
Note the text doesn't specify a direction for these tunnelled
protocols:
"Therefore, this document recommends the
DEFAULT operating mode for residential IPv6 simple security is to
permit all virtual private networking tunnel protocols to pass
through the stateful filtering function. These include IPsec
transport and tunnel modes as well as other IP-in-IP protocols."
[...]
This is the informative text in Section 2.2 of the Overview, whereas
the Detailed Recommendations are split between sections 3.2.4 and
3.2.5. I think it would be more helpful if you were to address your
concerns about sections 3.2.4 first, and 3.2.5 separately if necessary.
[...]
This would seem to me to allow unsolicited inbound tunnel
encapsulated traffic from any source, via any of the stateless over-
IPv6 tunnelling protocols or methods. I don't think that's very good
security at all, going slightly higher level than my earlier
example, here's the attack:
(1) purchase a banner add on a popular webpage, with the
advertisement image coming from your server, and use that to record
valid and current global unicast IPv6 addresses.
(2) attack those recorded addresses. Bypass all the v6 CPE security
measures specified in this draft by sending your malicious packets
inside an IPv6 in IPv6 or GRE in IPv6 tunnel.
With luck, the end-node has its own firewalling, and I think that is
fairly likely. The concern I have is that the CPE devices that will
be built to this draft will have a big "security" sticker on the
box, and yet it is so easy to bypass if we continue to permit all
unsolicited inbound stateless tunnelling protocols. If people see a
big "security" sticker on their CPE they may turn off their end-node
security, "because they don't need it anymore."
[...]
Having thought long and hard about the problem, I confess to not
viewing VPN protocols as a particularly important attack surface to
guard for residential networks. I think interior nodes configured as
vulnerable tunnel endpoints can be expected to be uncommon on
residential networks and limited only to those nodes where an
administrator has solicited inbound flows by some out-of-band method
invisible to any CPE firewall gateway. They are not very likely to be
present as a result of naïve user misconfiguration or the deployment
of ubiquitous-and-buggy legacy applications.
Requiring applications using tunnel protocols to use authentication
where it otherwise isn't needed adds complexity without providing any
*real* additional security. Some peer-to-peer applications, i.e.
those which do not require parties to authenticate with one another
until some time after unauthenticated communications have been
ongoing, will be given a perverse incentive to initiate with with
contrived anonymous credentials just to recover the transparency lost
to residential CPE filters that block unauthenticated inbound tunnel
flows.
At this point, what have you done? You've just shifted the attack
scenario above so that it looks like this:
(1) purchase a banner add on a popular webpage, with the advertisement
image coming from your server, and use that to record valid and
current global unicast IPv6 addresses.
(2) attack those recorded addresses. Bypass all the v6 CPE security
measures specified in this draft by sending your malicious packets
inside a tunnel using the well-known anonymous credentials widely used
by P2P applications for legitimately bypassing CPE simple security
measures.
In considering the recommendations in section 3.2.5, the IPv6
residential CPE simple security design team considered DEFAULT limits
on inbound IPsec and IKE flows, e.g. allowing only authenticated flows
or denying all inbound tunnel flows altogether, and came to rough
consensus that it couldn't be done in a way that A) would be
sufficiently simple for residential users, i.e. zero configuration,
and B) would provide any real improvement in the minimum baseline
security for the lowest common denominator of residential users,
without C) gravely damaging the utility of the public Internet for
everyone.
Do you agree with the design team that breaking IKE and IPsec
altogether by DEFAULT isn't acceptable?
If you don't break authenticated IKE and IPsec by DEFAULT, then a
specialization of the attack I describe above will still be possible,
and CPE router firewalls will not be in any position to guard against
it. Conversely, *unless* you break authenticated IKE and IPsec by
DEFAULT, then restricting all other flows will only serve as a
perverse incentive to use a contrived anonymous authentication in IKE
and IPsec (instead of the more appropriate and standards track BTNS)
when bypassing CPE simple security, because that's the only reliable
and legitimate way to initiate secure communications with residential
endpoints.
In fact, as BTNS is currently specified, limiting inbound flows only
to IPsec and authenticated IKE might still not reduce the attack
surface significantly. You'd have to specifically recommend breaking
BTNS with an IKE-layer filter, and even that would only stop the
*standard* method of anonymous authentication, not any of the non-
standard ones that would surely arise as legitimate methods of
bypassing CPE simple security.
In simple terms: it may turn out that the attack scenario under
discussion here cannot be addressed effectively in the long term
except by blocking inbound tunnel protocols *altogether*, including
IPsec and IKE, yet the price to pay for any mechanisms we recommend
now is a recurring one stretching indefinitely into the future for as
long as a significant fraction of the residential networks have CPE
deployed that follows the practice in this draft.
Is preserving the utility of inbound IKE and IPsec across residential
site boundaries really a controversial idea? Does the working group
believe that IKE and IPsec are flawed because they don't rely on
middleboxes to allow only "trustworthy" exterior nodes to initiate key
exchange and security associations with interior nodes? The design
team didn't believe so.
The design team also considered leaving inbound IKE and IPsec
unrestricted by DEFAULT while recommending stricter limits on other
inbound tunnels, but we were unpersuaded that the substantial loss of
network transparency would be an acceptable price to pay for the
meager reduction in attack surface area associated with them. Others
may disagree with the design team on that decision, and their opinions
are welcome in the working group discussion.
We don't believe we have been chartered to challenge the utility of
IPsec and IKE for exterior nodes initiating secure communications with
interior nodes protected by residential CPE simple security, and we
have taken care not to do so. The rest of our decisions relevant to
this discussion follow from that one.
To summarize, what you see above is the line of reasoning that led the
design team to specify sections 3.2.4 and 3.2.5 as they are in the
current draft. Are there objections to the detailed recommendations?
--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering