Re: [BEHAVE] NAT64: Security issues with funny addresses

Fred Baker <fred@cisco.com> Fri, 19 November 2010 21:02 UTC

Return-Path: <fred@cisco.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2DF328C132 for <behave@core3.amsl.com>; Fri, 19 Nov 2010 13:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.283
X-Spam-Level:
X-Spam-Status: No, score=-110.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-+M9YkRfLZH for <behave@core3.amsl.com>; Fri, 19 Nov 2010 13:02:52 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0BDE228C13A for <behave@ietf.org>; Fri, 19 Nov 2010 13:02:52 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggSABt15kxAaMHG/2dsb2JhbACbXoJjhCBxokibOIVLBIRYhgODDg
X-IronPort-AV: E=Sophos;i="4.59,225,1288569600"; d="scan'208";a="289480276"
Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 19 Nov 2010 21:03:34 +0000
Received: from [10.88.4.0] (sin-vpn-client-16-175.cisco.com [10.68.16.175]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAJL3WA0002059; Fri, 19 Nov 2010 21:03:33 GMT
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Fred Baker <fred@cisco.com>
In-Reply-To: <4CE6E135.7040700@viagenie.ca>
Date: Sat, 20 Nov 2010 05:03:32 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C888573-84CD-410E-B80C-BA4FFAE2C181@cisco.com>
References: <4CE6E135.7040700@viagenie.ca>
To: Simon Perreault <simon.perreault@viagenie.ca>
X-Mailer: Apple Mail (2.1082)
Cc: behave@ietf.org, Jean-Philippe Dionne <jean-philippe.dionne@viagenie.ca>
Subject: Re: [BEHAVE] NAT64: Security issues with funny addresses
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2010 21:02:54 -0000

On Nov 20, 2010, at 4:42 AM, Simon Perreault wrote:

> In draft-ietf-behave-v6v4-xlate-23, there is the following in the
> Security Considerations section:
> 
>   There are potential issues that might arise by deriving an IPv4
>   address from an IPv6 address - particularly addresses like broadcast
>   or loopback addresses and the non IPv4-translatable IPv6 addresses,
>   etc.  The [I-D.ietf-behave-address-format] addresses these issues.
> 
> I cannot find information on these issues in the referenced document
> (nor in RFC 6052).

We must have been looking at an earlier version of the document when we wrote that.

> So what should implementors do? Block them?

I would expect that the biggest issue is the fact of a replicated IPv4 address space. For example, Verizon says it has 70 instances of 10.0.0.0/8 in its network. Using a stateless translator, one could imagine it connecting them as 2001:dba:nnaa:bbcc:dd00::, where nn is an instance number and aa.bb.cc.dd (except converted to decimal) is the IPv4 address. This of course works just fine within the IPv6 part of the network or between IPv6 hosts in such a network and IPv4 hosts within any one of those IPv4 domains - they are completely separate addresses in IPv6. But it's not at all obvious how a computer (handset) in one of those domains addresses a computer in another using IPv4, and if it thinks it is doing so it has a good chance of talking to the wrong instance of that address. This is of course a primary failing of IPv4 NAT in general, it just happens to be under discussion in an IPv4/IPv6 scenario.

I don't know that I would recommend blocking them. I would simply recognize that there are some things that I won't be able to do, or won't be able to readily do, in a network that has replicated address space.

> It could be a major security issue in practice. Just thinking of this
> makes me nervous:
> 
> $ ssh 64:ff9b::127.0.0.1
> 
> Simon
> -- 
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave