Re: tunnel protocols (draft-ietf-v6ops-cpe-simple-security-03)

[james woodyatt <[e-mail]>]

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 <[e-mail]>
member of technical staff, communications engineering