[166904] in North American Network Operators' Group
RE: NAT64 and matching identities
daemon@ATHENA.MIT.EDU (Don Bowman)
Tue Nov 19 11:49:02 2013
From: Don Bowman <don@sandvine.com>
To: "Justin M. Streiner" <streiner@cluebyfour.org>, "nanog@nanog.org"
<nanog@nanog.org>
Date: Tue, 19 Nov 2013 16:48:29 +0000
In-Reply-To: <Pine.LNX.4.64.1311181455270.31342@whammy.cluebyfour.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
From: Justin M. Streiner [mailto:streiner@cluebyfour.org]=20
>It's looking more and more like NAT64 will be in our future. =20
>One of the valid concerns for NAT64 - much like NAT44 - is being
>able to determine the identity of a given user through the NAT=20
>at a given point in time.
>How feasible this is depends on how robust/scalable $XYZ's=20
>translation logging capabilities are, and possibly how easily that=20
>data can be matched against a source of identify information,=20
>such as RADIUS accounting logs, DHCP lease logs, etc.
... snip ...
We implemented a product around this. What we found in doing
so was that a) you need to use port-block allocation to make it feasible
(cannot do unbounded NATP where every flow gets its own port),
That AAA works well when the NAT is a gateway device, and that
Otherwise DHCP works ok, and syslog is the fallback. All devices
Supported one of those three.
We also found there was a need for IPV6 identification (e.g. some
customers used DNS reverse lookup in ipv4 to find the ID of a user
for e.g. single-sign-on type solutions, and this no longer worked
in a NAT44/NAT64/IPv6 environment.
We found there was a need for both real-time (e.g. query=20
who is this right now, e.g. sign-on), and after the fact (who
had this @ this time).
The general purpose coordinates we called 'session qualifiers', and
we found that sometimes it included VLAN or MPLS or other
tunnels.
Let me know if u want more info and I can follow up offline.
