Subject: [BEHAVE] comments on logging of NAT Events

From: Qiong <[email-masked]>
Date: Thu, 28 Jul 2011 15:46:17 +0800

Dear Fred, all,

With regard to NAT logging requirements, I think the listed tuple in this
draft is quite enough for our traceablity . However, since our major
difficulty is how to the handle huge amount of NAT logging event in a
centralized log server, we would like the logging event to be as simple as
possible.

In our deployment model, logging server is usually deployed at higher level
than LSN. This means it has to handle session-based logging events generated
by tens of gigabit/s of Internet traffic, not to mention that we even have
to store them for months. This would not only bring a great burden on
logging server, but also it would be quite expensive. So, we prefer to store
customer-based logging event (only include IPv6 address,
postNATSourceIPv4Address, port range, and timestamp), rather than
session-based logging.  Although most vendors we have tested already support
this feature, their data formats are quite different. I strongly agree that
NAT logging should be standardized in the near future.

Moreover, I'm wondering why do we need to have BIB create/delete logging
event. What does it designed for in case we already have session
create/delete event?

Maybe I have missed something during the behave meeting. Please correct me
if I missed something. :-)

Best wishes

Qiong Sun

---------- Forwarded message ----------
From: Fred Baker <[email-masked]>
To: IPv6 Operations <[email-masked]>
Date: Wed, 27 Jul 2011 16:29:51 -0400
Subject: [v6ops] Requirements for logging in NAT44, NAT64, and NPTv6
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.

---

From: ssenthil <[email-masked]>
Date: Thu, 28 Jul 2011 13:32:36 -0400

Please see inline.

On 7/28/11 3:46 AM, "Qiong" <[email-masked]> wrote:

> [Senthil] I think this is the challenge on how to optimize the data being
> logged as there are different ideas and different requirements surrounding the
> optimization. That¹s why this draft does not address the optimization
> techniques but just standardizing the formats and leave it up to the
> individual implementations to optimize it.
> 
> by tens of gigabit/s of Internet traffic, not to mention that we even have to
> store them for months. This would not only bring a great burden on logging
> server, but also it would be quite expensive. So, we prefer to store
> [Senthil] Ok, good.
> event. What does it designed for in case we already have session create/delete
> event?
> 
> [Senthil] Not all implementations do create sessions, most CGN implementations
> have only BIB entries (without the destination address/port information). The
> BIB create/delete events will be used in those circumstances. When you have a
> BIB entry, you would be able to log the destination information at the time of
> creation but not at the time of deletion.
> 
> Maybe I have missed something during the behave meeting. Please correct me if
> I missed something. :-)
> 
> Best wishes
> 
> Qiong Sun
> 
> 
> 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].
> 
> 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.
>