[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