Subject: [BEHAVE] Common issues with "Large NAT"

From: Alain Durand <[email-masked]>
Date: Tue, 18 Nov 2008 16:48:55 -0600

I'm using the "Large NAT" terminology to cover all CGN, DS-lite CGN, NAT64,
IVI, A+P, SAM, fractional IPv4 addresses, and any other method of sharing
IPv4 addresses among potentially many subscribers.

All the above large NATs share a number of issues:

1) port distribution / port reservation / port negotiation & variants of
that

We need to distinguish between port for outgoing connections and incoming
ones. For outgoing connections, the actual port number is usually
irrelevant.

I would like to bring an observation that comes from actual measurement: the
average number of outgoing port per customer is much much smaller than the
maximum number of port an average customer can use at any given time...
This means that an algorithm that dynamically allocates outgoing port number
from a central pool are much more efficient than algorithms that statically
divide the resource by pre-allocating a fixed number of port to each
subscribers.
For incoming connections, the situation is different. The actual port
numbers allocated to customer do matter as they are part of external
referrals, ie used by 3rd party to contact a service run by the user.
Moreover, it would be desirable to make sure those incoming port remain
somehow stable over time...
Still, early measurement seems to indicate that only very few ports are used
in average by customers for incoming connections.

This means that we do not necessarily have to pre-allocate a large number of
port to subscriber, but can either pre-allocate a small number of port
number for incoming connections or do port allocation on demand when the
application receiving connection starts and reserve the bulk of ports as a
centralized resource shared by all subscriber.

2) connection to well know port number

Those would not work in the general case. However, some work around can be
put in place, like redirects to port-specific URL.

3) UPnP

Using the UPnP semantic, a client is asking "I want to use port number X, is
that ok?" and the answer is yes/no. If the answer is no, the client
typically try the next port, until it either finds one that works or gives
up after a limited number of attempts. UPnP has, currently, no way to
redirect the client to use another port number.

NAT-PMP has a better semantic here, enabling the NAT to redirect the client
to an available port number.

4) Security & identification of subscriber with IPv4 addresses

When an abuse is reported, it is usually done in the form: IPv4 address X
has done something bad at time T0. This is not enough information to trace
back the problem when that IPv4 address can be used by a large number of
subscribers. This particular issue can be fixed by logging port numbers.

A number of servers are tracking IPv4 addresses to protect from certain
attacks. For example, if a server see too many login attempts from the same
IPv4 address, it may decide to put that address in a penalty box for a
certain time. If an IPv4 address is shared by multiple subscriber, this
would have unintended consequences.

Moreover, the IPv4 addresses == user assumption is used for geolocation,
counting the number of individual users, etc... All those things may break
when an IPv4 address will be shared by several subscriber at the same time.

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Nov 2008 18:47:49 -0600

> to an available port number.

FWIW, I've been working on a v4/v6 NAT proposal called nat-xc (for nat
with explicit control) that has a more general API - it is agnostic
about whether the client makes a request over v4 or v6 and about whether
the client asks for a v4 or v6 address/port.  And it lets the client ask
either for a specific address and port or to have either of them be
assigned by the translator.  It's also designed to work through legacy NAT.

draft-moore-nat-xc-* (currently * = 01, but I'm working on a rev which
might be out before the end of the week)

Keith

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 20 Nov 2008 21:34:02 +0200

> assigned by the translator.  It's also designed to work through legacy NAT.

If I understand the proposal, it's essentially a transparent variant of SOCKS, 
hidden below the socket API?

> draft-moore-nat-xc-*
        ^^^^^ ^^^
I guess "people working on NAT traversal are" not "all idiots" anymore.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Nov 2008 14:32:50 -0600

> hidden below the socket API?

Sort of.

NAT-XC is a packet translator/forwarder.  IIRC socks is a transport
forwarder, or it multiplexes commands and data on the same channel. (I
don't remember which).

NAT-XC defines a protocol to manage bindings in the translator, similar
in concept to the TURN protocol, though it differs from TURN in a number
of important aspects.  The NAT-XC protocol can work regardless of
whether the translator is stateless or stateful.

The NAT-XC control protocol _can_ be hidden below the socket API.  It
can also be implemented in a network stack.  It can also be used as the
interface between two halves of a "split NAT" (whether NAT46 or NAT64 or
NAT44 or whatever) where one half of the NAT is a router that sits on
the customer's network and decides what address bindings it needs to
create/renew/destroy, and the other half is the part that sits in the
intersection of public v4 and public v6 space and does the actual
translation and forwarding.

And of course the protocol can be used directly by an application if it
wants or needs to do that.  The trick is to give control to the
application, or the layer closest to the application that wants control.
 That way, you can give the application a way to avoid DNS ALG and other
ALGs that would otherwise get in its way.  (while leaving those ALGs
there for use by legacy apps that need them).

> I guess "people working on NAT traversal are" not "all idiots" anymore.

My goal is to make v6 (and the combined v4/v6 world that exists in the
interim) safe for applications.

For the sake of contrast, my goal is _not_ to define ways of traversing
existing NATs.  Rather, I accept that some sort of network translation
is needed to allow v4 and v6 to talk to each other, so I set about
seeing how to do it in as application-friendly a way as possible.

It turns out that what applications need in order to cope with address
translation are things that BEHAVE and other groups have been providing
(or recommending) in a piecemeal fashion.  e.g. the ability to listen at
a public address:port, the ability to know what your public address is
and to let it be used by arbitrary peers, the ability to manage binding
lifetimes in UDP or across multiple TCP sessions.

So in a sense I've arrived at a similar place that BEHAVE has, but via a
different path.

And I think that it would make no sense to have to repeat that
evolutionary process for v4/v6 NAT, nor to have to deal with piecemeal
mechanisms.   Nor do I think it makes any sense to require applications
in a v4/v6 world to have to provide their own intermediaries to serve as
rendezvous points to arrange for hole punching through the NATs, when
there's already a programmable translator box there anyway.

So I'd argue that v4/v6 translation mechanisms need to have a standard,
built-in api for managing bindings, listening to public addresses, and
learning the public address associated with the bindings.  NAT-XC is an
attempt at defining such an API and architecture.

Keith

p.s. I still don't know how to make a good v4/v4 NAT.  Re-using the same
address space in different realms is the limiting factor.  But we don't
have that problem in v6, or with translation between v6 and v4.  So
v4/v6 NAT can fundamentally be a lot saner than v4/v4 NAT.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave