用来对付互联网上广泛应用的TCP（传输控制协议）协议存在问题的解决方案日前出台。出现的问题是带有恶意的第三方冒充成合法的发件人，可能切断通信或是把数据偷换成非法内容。原因是TCP中存在漏洞，不对数据包中所含数据的合法性进行判断。如果发件人以及发件人的IP地址与端口号码、序列号（sequence number）正确，即使是含有非法数据的数据包，机器也能象平时一样接收。其实，“这一问题早就发现了”（JPCERT处理协调中心，以下称JPCERT/CC），但到目前为止还没有合适的解决方案。

    此次的解决方案是Paul Watson提出的。Paul Watson在2004年4月21日于加拿大举办的“CanSecWest 2004”会议上发表了该方案，与此同时英国NISCC（国家基础设施安全协调中心）公布了有关漏洞的情况。在日本国内，在计算机安全发生问题时促进信息共享的非营利团体JPCERT/CC发表了NISCC所提供的信息。

    IETF（互联网工程任务组）已将这一提案以草案的形式公开。具体而言，就是通过三种手段解决问题。比如，这样处理设置复位（RST）标志（Flag）的非法数据导致通信中断的问题：接收到RST数据包的发送方机器，确认数据包的序列号，检查序列号是否紧挨以前接收到的数据包号码。如果不是紧挨着的号码，请求发送方再次发信。所谓序列号，是一个32位数值，表示包括该数据包的数据相当于每个数据包被分割之前原数据的哪一部分。由于此次的解决措施没有改变收发数据包的标准，因此只需在收信方的机器上采取这一措施即可。

    在诸如BGP（边界网关协议）等TCP会话时间长的通信中，极有可能被第三者发现IP地址与端口号码，因此这一问题就可能造成严重后果。另外，由于为了提高通信速度，越来越多的情况下把窗口尺寸（Windows Size）设置得较大，而第三者就很有可能凭借推测猜中设置的序列号。因为可先行发送的数据包数——窗口尺寸越大，目标机器可顺利接收的序列号的种类就越多。不过，象HTTP这样和TCP会话时间短的通信，接到IP地址、端口号码等信息完全一样的假冒数据包的可能性很小。“眼下并不存在危险”（JPCERT/CC），不过这一解决方案很有可能会追加到IETF公开的互联网相关资料“RFC（Requests For Comments）”中。