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

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Nov 2010 15:42:29 -0500

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).

So what should implementors do? Block them?

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

---

From: Fred Baker <[email-masked]>
Date: Sat, 20 Nov 2010 05:03:32 +0800

> I cannot find information on these issues in the referenced document

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.

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

---

From: Christian Huitema <[email-masked]>
Date: Fri, 19 Nov 2010 21:25:20 +0000

> (From Simon Perreault)

>From RFC 6052, page 8:

   3.  Deployment Guidelines

   3.1.  Restrictions on the Use of the Well-Known Prefix

      The Well-Known Prefix MUST NOT be used to represent non-global IPv4
      addresses, such as those defined in [RFC1918] or listed in Section 3
      of [RFC5735].  Address translators MUST NOT translate packets in
      which an address is composed of the Well-Known Prefix and a non-
      global IPv4 address; they MUST drop these packets.

I believe that is quite specific.

> From Fred Baker:
> I would expect that the biggest issue is the fact of a replicated IPv4 address space. 

RFC 6052, page 9:

   3.3.  Choice of Prefix for Stateless Translation Deployments
   ...
      Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
      a Network-Specific Prefix to their IPv4/IPv6 translation service.

This recommendation, if followed, will ensure that IPV4 addresses generated from private deployments will not end up conflicting with addresses used in other deployments.

-- Christian Huitema

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Nov 2010 16:33:03 -0500

> I believe that is quite specific.

Thank you! This is exactly the guidance we were looking for. I was
searching in the wrong place.

Simon