Subject: [v6ops] Requirements for logging in NAT44, NAT64, and NPTv6

From: Fred Baker <[email-masked]>
Date: Wed, 27 Jul 2011 16:29:51 -0400

This afternoon, in behave, there was a brief discussion of NAT logging. behave has a draft in progress, but has no real idea how it relates to enterprise or service provider logging requirements. What would really help would be for network operators with NAT logging requirements (most likely broadband service providers, mobile service providers, and educational or enterprise networks with similar requirements) to review the draft and comment to [email-masked].

The draft is http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging
  "Logging of NAT Events", Senthil Sivakumar, Reinaldo Penno, 13-Jul-11

My perception is that the primary NAT logging requirements derive from forensic requirements, and potentially differ based on regional or national requirements - important requirement sets include US, European, Australian, Japanese, and Chinese directives. I would summarize them in this way:

 - With stateless NAT64, I don't think there is a need for translation logging, as it is statelessly predictable. 

 - There are legal requirements around logging for NAT44 and stateful NAT64, primarily around forensic requirements. I believe that comes down to, when configured, a message with a timestamp, an interface identifier, and an address/port (IPv4 or IPv6) four-or-five-tuple. Given that this would happen on the first packet to cross the NAT, there would be no data retention capability in the same message - data retention requirements for NAT44, stateful NAT64, and stateless NAT64 would have to be met by IPFIX, much as they are now.

It probably also implies a statement that this is Internet layer information; one cannot expect it to come up with email addresses, URLs, instant messaging handles, or other wishful thinking we have read in ill-informed legal documents.

This implies a capability (tool) to interpret the two databases in response to legal inquiries.