Subject: [BEHAVE] Re: CPE equipments and stateful filters

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 11:30:40 -0700

[ Added BEHAVE working group. ]

On Jul 27, 2007, at 19:44, Fred Baker wrote:
>
> [...] Alain's comment in the plenary Thursday evening that James  
> document and my comments on this list advocate NAT are, in the best  
> possible case, incorrect - nobody is talking about NAT in IPv6,  
> although I do believe that there will be places that network  
> operators choose to use that class of capability. In the worst  
> case, it constitutes a deliberate misstatement calculated to cause  
> confusion and troll for a flame war in this venue. I choose to  
> believe the former, although I ask myself the question. [...]

I wasn't present for the plenary, so I don't know what M. Durand  
said, but let me clarify my position, which I believe is best  
characterized as a "warning that we have not quite succeeded in  
making NAT obsolete" with IPv6.

The need to implement what I am now calling "application transparency  
helpers," which function like ALG modules in an IPv4/NAT firewall,  
but which only help control transport filtering state in response to  
application protocol content without actually coordinating any UNSAF  
function like an ALG does, is a vector by which NAT implementations  
may worm their way back into the IPv6 architecture.

I'm currently looking at source code in OpenBSD PF that appears  
designed to use IPv6-NAT to redirect application flows to userland  
proxies for exactly this purpose.  IPv6 support for an FTP  
"transparency helper" is on my list of things I expect to need, and  
using an IPv6 NAT to redirect FTP control flows in and out of my  
existing IPv4 FTP proxy looks like the obvious shortest path to  
working code.  (Similar things will need to be done with all the  
other major application protocols.)

If IPv6 NAT were truly obsolete, this wouldn't be the case, but it  
is.  Hence, my warning.

Coming away from IETF 69 in Chicago, I'm now convinced that IETF will  
not be revisiting its consensus that the public IPv6 internet is  
intended to be clients behind multiple layers of firewalls  
communicating mainly through mediation services in data centers.  I'm  
certain my employers will have no trouble adapting to this reality.

I'm no longer certain that IPv6 will ever be a suitable replacement  
for IPv4/NAT in residential settings, but I see reasons to be hopeful  
that all is not lost on that account.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 12:15:11 -0700

> -----Original Message-----
> From: james woodyatt [mailto:[email-masked]] 
> Sent: Monday, July 30, 2007 11:31 AM
> To: IPv6 Operations; Behave WG
> Subject: [BEHAVE] Re: CPE equipments and stateful filters
...
> other major application protocols.)

Application-aware ALGs are bad.

Passive-mode FTP (using the "PASV" verb) has been supported on 
all modern FTP clients and FTP servers for a long time (going on a 
decade for most FTP clients and FTP servers).  Passive-mode FTP 
causes the TCP data connection to be initiated by the FTP client (as 
is the TCP control connection), which eliminates the need for any ALG 
or ALG-like function in NATs and in firewalls.  Is there a reason 
passive FTP can't simply be mandated for v6, so we can avoid FTP-aware
ALGs?

> communicating mainly through mediation services in data 
> centers.  I'm certain my employers will have no trouble 
> adapting to this reality.
>
> for IPv4/NAT in residential settings, but I see reasons to be 
> hopeful that all is not lost on that account.

I do hope you pursue a BoF in Vancouver to discuss the need for 
endpoints to communicate to firewalls in IPv6.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 30 Jul 2007 22:17:49 +0300

> other major application protocols.)

As far as I know, EPSV is recommended against EPRT, so I fail to see a 
problem for that *particular* protocol. I understand many legacy FTP 
clients use PORT by default, but these cannot do IPv6 anyway.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 12:51:23 -0700

> Application-aware ALGs are bad.

They are better than nothing.

> passive FTP can't simply be mandated for v6, so we can avoid FTP-aware

No.  Passive-mode FTP is broken for exterior clients connecting to  
interior servers by stateful packet filters.  Merely allowing the FTP  
control port through the filter to the interior server is  
insufficient.  Requiring FTP clients and servers to use TCP  
simultaneous open for data connections could address this problem,  
but I've been using FTP as an example to illustrate the wider problem  
with applications in general.

We still have an open problem regarding IKE and IPsec ESP/AH, and I  
don't see a comparable way to resolve it without an application  
transparency helper or by allowing inbound ESP/AH by default.   It  
remains to be seen whether consensus will emerge around the latter  
solution, so I contend the former remains an open problem.

There are similar issues with RTSP and RTCP/RTP flows.  And other  
existing application protocols.  Not to mention applications not  
imagined by their developers yet.  And and and.  So long as the IPv6  
architecture is defined such that communications between endpoints  
are always expected to originate with nodes behind firewalls and  
mediated by services in data centers, we will be saddled with the  
need for either 1) application transparency helpers inside network  
firewalls, and/or 2) an improvement to the core IPv6 specifications  
along the lines of my Application Listener Discovery (ALD) proposal.

> endpoints to communicate to firewalls in IPv6.

I'm working on socializing that plan with my management.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 30 Jul 2007 23:30:05 +0300

Le lundi 30 juillet 2007, james woodyatt a écrit :
> So long as the IPv6

I would not that the architecture is defined such. First, because the 
IETF, as an SDO, has an history of NOT specifying architectures. 
Second, because there is clearly NOT a consensus on that topic.

*But*, I would agree that, in any case,
- whatever the IETF mandates, recommends, suggests, or not,
- whether or not this is a good idea,
- whether or not it abides to the IETF design principles,
- whether ir not this is good engineering,
- whether it displeases some consumer ISPs,
- whether it breaks IETF transport protocols,
- whether it breaks IETF mobility protocols [1],
- whether or not it makes IPv6 rather useless compared to IPv4+NATs,
- ...

...there will be stateful firewalling middleboxes in some "unmanaged" 
network cases. And it will also definitely happen on consumer-grade 
radio links.

--- Footnote: ---
[1] Mobile IPv6 has been notoriously absent from this debate so far. It 
is all the weirder as it has been at the center of another recent IETF 
IPv6 hot topic: RH0 deprecation.
---

Therefore, as an individual, I think there would be value for IETF in:

- working on ALD or something along its line,

and,

- working on BEHAVE-ish recommendations for such boxes, to minimize the 
damage to the works of the IETF Transport and Internet areas (and 
indirectly the RAI and Apps areas). By this, I mean non-UDP transport 
protocols, mobility/multihoming stuff, and some future proofing.

My 2 cents,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 13:33:47 -0700

> From: Gert Doering [mailto:[email-masked]] 
> Sent: Monday, July 30, 2007 12:33 PM
> To: Dan Wing
> Cc: 'james woodyatt'; 'IPv6 Operations'; 'Behave WG'
> Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters
> 
> Hi,
> 
> On Mon, Jul 30, 2007 at 12:15:11PM -0700, Dan Wing wrote:
> > passive FTP can't simply be mandated for v6, so we can 
> > avoid FTP-aware ALGs?
> 
> Correct me if I'm wrong - but you'll need "firewall support" for 
> PASV / EPSV ftp as well, just on the other side of the connection.
> 
> If you run your server behind a firewall (which is a pretty 
> common thing
> to do), and want to offer FTP services, the firewall needs to 
> know which port to open for PASV connections.

You are certainly right that such a firewall protecting the 
FTP server needs to open pinholes for the incoming TCP data 
connection when using PASV.

(We could argue about the commonality of such a configuration,
but there isn't much point in such an argument; the need 
for hosts to communicate the desire for incoming connections
to the firewall is what's important.)

-d

> Gert Doering
>         -- NetMaster
> -- 
> Total number of prefixes smaller than registry allocations:  113403
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. 
> Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 15:47:34 -0700

> insufficient. 

You're right.  Thanks for pointing out my mistake in assuming
the FTP server wouldn't, itself, be behind a similar firewall.

> Requiring FTP clients and servers to use TCP  
> but I've been using FTP as an example to illustrate the wider 
> problem with applications in general.
> 

I don't see why you'd allow unsolicited ESP or AH, but deny other
protocols (ICMP, UDP, TCP, SCTP, DCCP).  It seems we need to solve
this problem for all protocols.  Certainly, if one is considering
a battery-powered host, where receiving any packet will wake up
the radio and host processor, unsolicited IPsec packets shouldn't 
be allowed any more so than unsolicited UDP or TCP.

> There are similar issues with RTSP

RTSP control traffic over TCP?

> and RTCP/RTP flows. 

At this point, ICE (draft-ietf-mmusic-ice) is believed to provide
a viable, incrementally deployable mechanism for IPv4 and IPv6, 
including if you're behind a NAT or firewall if that NAT or firewall
allows packets from inside->outside to create permissions for 
outside->inside; most NATs available to consumers work like that
and all firewalls can be configured like that.

> And other  

I see ALD being helpful for both the case of talking to a well-
known server in a datacenter, and also being helpful for peer-to-
peer applications, such as running an FTP client when you're behind
a firewall trying to communicate with an FTP server that is also behind
a firewall.

> I'm working on socializing that plan with my management.

Good deal.

-d

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 16:31:43 -0700

On Jul 30, 2007, at 15:47, Dan Wing wrote:
> [I wrote:]

Yes.  As seen in QuickTime and RealPlayer applications.

> and all firewalls can be configured like that.

Existing code (which does support IPv6) has no support for ICE.

Even in the event ICE isn't deployed, how do you recommend I resist  
the inevitable pressure to implement an application transparency  
helper for these A/V streaming applications?  I'm still having to  
maintain ALG's in IPv4/NAT for various VPN protocols even though we  
have long had standards track protocols for IPsec encapsulated in UDP  
and negotiating NAT traversal of IKE.

I'm expecting to have to implement a helper for IKE and IPsec ESP/AH  
in IPv6.  Without it, I expect route optimization in Mobile IPv6 to  
be broken, since mobile nodes are supposed to bind with their home  
agents using an IPsec ESP security association.  In fact, the more I  
read about route optimization in MIPv6, the more convinced I am that  
it represents the most glaring illustration yet of our failure to  
consider properly the implications of recommending the widespread  
deployment of stateful middlebox packet filtering in IPv6 networks.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 17:28:02 -0700

> helper for these A/V streaming applications? 

With ICE, such application helpers are not necessary.  This was one
of the major design decisions in ICE.  This is the same design 
descision that allows Skype to "work anywhere".  

> I'm still having to  
> have long had standards track protocols for IPsec 
> encapsulated in UDP and negotiating NAT traversal of IKE.

The only IPsec client implementation I'm aware of is Cisco's, and
I know our implementation does not provide automatic detection or
fallback from IPsec-over-IP to IPsec-over-UDP; rather, the user has
to select this themselves or be artificially limited to always use
UDP.  IPsec-over-UDP is, of course, less bandwidth efficient than
IPsec-over-IP.

It's important to have such automatic fallback mechanisms.  ICE
provides these automatic fallbacks by using connectivity checks.

We know how to multiplex those connectivity checks with RTP/RTCP, 
DTLS, TLS, HIP, and SIP.  I expect ICE connectivity checks could
be multiplexed with many other protocols.  I am not suggesting ICE
is the ideal solution for a host to tell its v6 firewall that it
desires incoming traffic -- I am just explaining how ICE works 
as a datapoint.  You may find it valuable to read the first 
two sections of ICE (and ignore the detail).  Also, Jonathan 
Rosenberg gave an ICE tutorial in Chicago, posted at 
http://www.jdrosen.net/papers/ice-ietf-tutorial2.ppt.  Like you,
I wasn't present at the Thursday technical plenary but I listened
to the audio,
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch5-thurs-
afnoon-plenary.mp3

> deployment of stateful middlebox packet filtering in IPv6 networks.

http://tools.ietf.org/html/draft-tschofenig-mip6-ice-01 describes 
how ICE might be useful for Mobile IPv6.

-d

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 17:56:08 -0700

On Jul 30, 2007, at 17:28, Dan Wing wrote:
>
> <http://tools.ietf.org/html/draft-tschofenig-mip6-ice> describes  

I'm reading this draft now.

It's fascinating.  The authors apparently assume the deployment of  
IPv6 NAT.  I wonder why.

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 19:01:33 -0700

> I'm reading this draft now.

If I understand how this might work, it would involve encapsulating  
IPsec ESP and IKE in UDP, to transit firewalls between MN's and their  
HA's, using conventional UDP state tracking.

We don't currently have any protocol whereby IKE decides to switch  
over to UDP encapsulation, except in the NAT-traversal case, do we?   
With IPv6, we still think we have no NAT, so tests for reflexive  
addresses to match IKE initiations will always succeed.

What triggers the switch to UDP encapsulation?  The mobility layer  
trying to do STUN connectivity tests on the ESP protocol?  Blech, but  
I guess it works most of the time.  If it fails mysteriously, just  
try again-- that seems to be a common failure recovery method in  
human-centered systems.  I can't say I approve of it.  For one thing,  
I really don't like the idea of extending my implementations of IPsec  
and IKE to do STUN over protocol=50 and port=udp/500.

RFC 4487 describes additional issues, e.g. CN's reaching MN's that  
roam behind networks with firewalls.  <http://tools.ietf.org/html/ 
draft-bajko-mip6-rrtfw> proposes a way to work around the RRT issue,  
which looks on its face to be an ugly but workable hack.  It reminds  
me that <draft-ietf-v6ops-cpe-simple-security> needs to be very  
explicit about how to handle the mobility extension header.

Finally, <http://tools.ietf.org/html/draft-tschofenig-mip6-ice> seems  
not to care at all about the problem of home agents behind  
firewalls.  RFC 4487 raises that issue, but I'm not seeing how M-ICE  
is supposed to address it.  Did I miss something?

My head hurts trying to sort out all the questions I have about ways  
these approaches potentially might fail during incremental  
deployment.  On the other hand, all this stuff seems a lot simpler--  
though still pretty soul-killingly fragile-- with ALD in the mix.  I  
still think we'd be better off without any SPF middleboxes.  (Oh, by  
the way, I remember now why I'm not optimistic about firewalls  
helping keep denial-of-service traffic off first mile links.  That's  
a topic for another message, though.)

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 23:43:03 -0700

> On Mon, Jul 30, 2007 at 05:28:02PM -0700, Dan Wing wrote:
> This is again assuming "the IPSEC session is initiated outbound-only,
> and the IPSEC server (gateway, whatever) is in a corporate 
> data center".
> 
> In an end-to-end world, it may be desirable to have one residential
> user setup IPSEC to another residential user.  Both behind 
> such stateful firewalls that neither permit unsolicited 
> inbound UDP.

In such a case, they need to communicate each others IP addresses
(and perhaps UDP ports) using a rendezvous protocol (such as SIP,
see draft-saito-mmusic-sdp-ike-01.txt) in order to allow one (or both)
to allow inbound UDP (or 'raw' IPsec), or the server would need to 
tell its firewall to permit unsolicited incoming traffic.

-d

---

From: Gert Doering <[email-masked]>
Date: Tue, 31 Jul 2007 08:27:12 +0200

Hi,

This is again assuming "the IPSEC session is initiated outbound-only,
and the IPSEC server (gateway, whatever) is in a corporate data center".

In an end-to-end world, it may be desirable to have one residential
user setup IPSEC to another residential user.  Both behind such stateful
firewalls that neither permit unsolicited inbound UDP.

Gert Doering
        -- NetMaster

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Tue, 31 Jul 2007 08:27:12 +0200

Hi,

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 31 Jul 2007 08:58:22 +0200

Hi,

> tell its firewall to permit unsolicited incoming traffic.

Which seems to be the point of this discussion.  "If we are going to 
have stateful firewalls, due to popular belief that this is a good thing, 
how to tell the firewall that it should stop disturbing traffic".

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Mon, 30 Jul 2007 21:33:04 +0200

Hi,

If you run your server behind a firewall (which is a pretty common thing
to do), and want to offer FTP services, the firewall needs to know which
port to open for PASV connections.

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Tue, 31 Jul 2007 10:19:52 -0700

On Jul 30, 2007, at 23:43, Dan Wing wrote:
>
> ...or the server would need to tell its firewall to permit  
> unsolicited incoming traffic.

It would be more accurate to describe that method like this: the  
server would need to solicit the firewall to permit 1) inbound IKE  
initiations from arbitrary remote addresses, and 2) IPsec ESP/AH  
flows for negotiated security associations.  Neither of these two  
forms of traffic could reasonably be described as "unsolicited" in  
this case.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Jul 2007 10:46:37 -0700

> flows for negotiated security associations. 

Agreed.

> Neither of these two  

We have different definitions of 'solicited traffic' and 
'unsolicited traffic'.  Other than opening a listener on UDP/500 
for IKE (and telling the upstream firewall to please open a 
permission for incoming traffic), the host didn't do anything to
solicit an incoming IKE packet.  I call that incoming traffic
'unsolicited', because the host (and its firewall) are unaware
of when a client will send a packet to establish a connection.
An HTTP server or SMTP server fall into this category, for 
example.

This differs from the SIP model and the RTSP 2.0 model.  In
both SIP and RTSP 2.0, an offer/answer exchange allows the 
server to learn the client desires a new session.  With that
knowledge, the server can communicate more specific information
to its firewall about the client's IP address; in this way, the
firewall doens't need to necessarily permit incoming IKE packets
from arbitrary remote addresses, unless those are first signaled
with SIP or RTSP.  This model is also used by HIP and EME, two
working groups in the IRTF (www.irtf.org).  This is what I would
consider 'solicited traffic'.

What are your definitions?

-d

---

From: james woodyatt <[email-masked]>
Date: Tue, 31 Jul 2007 12:08:21 -0700

On Jul 31, 2007, at 10:46, Dan Wing wrote:
> [ I wrote: ]
>> Neither of these two forms of traffic could reasonably be  
>> described as "unsolicited" in this case.
>
> 'unsolicited traffic'.

That seems to be the case.

> What are your definitions?

I have a more human-centered view of what it means for traffic to be  
solicited: if a human network administrator is expecting the traffic,  
then any protocol or method initiated by an administrator for the  
purpose of enabling an exception to the "denial by default" policy is  
an explicit solicitation.

For example, an HTTP or SMTP server could solicit inbound connections  
by sending an NSLP CREATE/EXT message to the appropriate NSIS  
responder.  A more common scenario might be the case where an Apple  
File Sharing (AFP) protocol server advertises a DNS-SD record with  
wide-area Bonjour™ and opens an IPv4/NAT translation for it with NAT- 
PMP.

---

From: [email-masked]
Date: Tue, 31 Jul 2007 15:40:53 -0400

YES!  Definitions are very important here, or we'll wind up talking in 
circles. 

> ... We have different definitions of 'solicited traffic' and 
> 'unsolicited traffic'. ...

Interesting observations Dan.  The differences are around what prior 
knowledge is available.  I think it can be generalized and expanded. 
(Whipping out my handy dictionary.) 

> I call that incoming traffic [intentionally listened for]
> of when [or from where] a client will send a packet to establish 
> a connection.

"Unsolicited" does seem to be a good term for this category.  Perhaps 
"Expected" would be a good characterization also. 

> ... [some protocol] exchange allows the 
> to its firewall about the client's IP address [and timing 
> of the required pihole]; ...  This is what I would

Yup, "Solicited".  "Negotiated" or "Signalled" might also be appropriate 
terms.    Note also, the actual signalling, leading up to the Solicited 
traffic, may well have been some other category. 

I would add: 

"Unexpected / unwanted" -- traffic which was not explicitly indicated as 
ready to receive, either by listening at the server and (potentially) 
opening the corresponding pinhole in the firewall (either of Unsolicited 
or Solicited above), or by client initiation (next).   This is the "bad 
stuff" that should be dropped on the floor. 

"(Client) Initiated" -- traffic that started from the "inside", by the 
client. 

Just typing out loud... 

-- Peter Blatherwick

"Dan Wing" <[email-masked]>
Sent by: [email-masked]
31.07.07 13:46
 
        To:     "'james woodyatt'" <[email-masked]>, "'IPv6 Operations'" 
<[email-masked]>, "'Behave WG'" <[email-masked]>
        cc: 
        Subject:        RE: [BEHAVE] Re: CPE equipments and stateful 
filters

Agreed.

-d

---

From: Christian Huitema <[email-masked]>
Date: Tue, 31 Jul 2007 18:01:44 -0700

> An HTTP server or SMTP server fall into this category, for

It makes a ton of sense to just leave the IKE port (UDP 500) open. IKE
is a fairly robust protocol, with built in protection against DOS. It is
part of the security suite, and thus the software implementations tend
to be scrutinized and well tested. At the end of the IKE exchange, the
parties have identified each other, and have made a conscious decision
to authorize the communication. Clearly, the follow on traffic may be
"unsolicited", but it will not come from random parties. Leaving port
500 open looks like good engineering!

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Tue, 31 Jul 2007 20:01:49 -0700

On Jul 31, 2007, at 18:01, Christian Huitema wrote:
>
> It makes a ton of sense to just leave the IKE port (UDP 500) open.

I agree.  I think <draft-ietf-v6ops-cpe-simple-security> says to do  
this.  If it doesn't, then the next revision (coming soon) will say it.

The argument against doing this, which I've heard at least one WG  
Chairman offer me, is that leaving any port or protocol open to all  
inbound traffic exposes the interior network to denial of bandwidth  
attacks (along with potentially draining the batteries of portables  
in power-save mode).

The more I've thought about that problem, the more I've come to  
believe that using stateful filtering middleboxes to counter the  
threat is like responding to the possibility of your house eventually  
being attacked by a swarm of mosquitos by always keeping your living  
room filled with carbon monoxide.  Yes, you've prevented the  
mosquitos, but you've also denied yourself access to your living room.

The traditional way you control mosquito populations is with taxpayer- 
funded pest control services going through the neighborhood, spraying  
insecticide into all the standing water collectors to keep them from  
breeding.  Something similar to that, I think, is the proper way to  
engineer an Internet pest control program.

If I ruled the world with an iron fist, operating a zombie-- even  
unknowingly-- would get your IP dial-tone terminated at your  
demarcation point, and you'd have to submit to an audit to get it  
turned back on again.  Carriers who didn't do this would see their  
peering jeopardized, then degraded, and finally dumped, with their  
contracts thrown into liquidated damages.  Failure to police your  
peering points would be grounds for operators in the DFZ to apply  
filters, limiters and/or delays on your prefixes in the global  
routing tables.  Operators who didn't like this could complain to  
their governments, which would then decide whether and how to go to  
the World Trade Organization.

When the zombie apocalypse hits, I want all the walking dead to be  
nuked from space.  It's the only way to be sure.  Alas, I don't rule  
the world.  We'll probably be stuck with a solution much more  
jackbooted and less effective.  Like stateful filtering middleboxes  
that have to be told to open pinholes for the IKE port.