Subject: [BEHAVE] Adopting NAT logging as WG item

From: ssenthil <[email-masked]>
Date: Mon, 16 May 2011 22:47:13 -0400

There is a need for CGNs to log connections, as mentioned in
draft-ietf-intarea-server-logging-recommendations. However, we lack a
standard for this logging.
 
I propose the working group consider draft-sivakumar-behave-nat-logging as a
document to fulfill that need.
http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-01

Thanks
Senthil

---

From: Tina Tsou <[email-masked]>
Date: Mon, 16 May 2011 22:27:18 -0700

Senthil,
Do you think this should be considered as a package?
https://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reduction/

We keep our promises with one another - no matter what!
 
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ssenthil
Sent: Monday, May 16, 2011 7:47 PM
To: [email-masked]
Subject: [BEHAVE] Adopting NAT logging as WG item

Thanks
Senthil

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 17 May 2011 08:14:24 -0400

Hello Senthil,

I'm familiar with your doc but If the WG would like to standardize logging
we should iron out the information model and then each party is free to map
that to the protocol of choice (IPfix, Binary Log, Raw CSV, etc). Something
like 'CGN Logging Information Model'.

Therefore I would prefer a document that specifies which information is
needed in the case of address sharing and how it should be represented:
timestamp (open-close), private ip, public IP, public port, etc.

Other considerations are needed, e.g., in case of DS-Lite softwire ID would
be needed, and with overlapping IPs the VRF (or equivalent) should be
present, etc

Thanks,

Reinaldo

On 5/16/11 7:47 PM, "ssenthil" <[email-masked]> wrote:

> draft-ietf-intarea-server-logging-recommendations. However, we lack a standard
> for this logging.
>

---

From: ssenthil <[email-masked]>
Date: Wed, 18 May 2011 01:11:56 -0400

I see reduction of logs as an optimization and there are many ways to
optimize, my draft considers that out of scope.
But if the WG consensus is to have it integrated I will be fine with it.

Senthil

On 5/17/11 1:27 AM, "Tina Tsou" <[email-masked]> wrote:

> We keep our promises with one another  no matter what!
>  
> Best Regards,
> Tina TSOU

---

From: ssenthil <[email-masked]>
Date: Wed, 18 May 2011 01:16:43 -0400

> timestamp (open-close), private ip, public IP, public port, etc.
Maybe I am confused, the logging draft in fact is attempting to specify what
information elements are to be logged. It leaves it up to the implementation
on choosing the transport (ipfix, netflow etc).

> be needed, and with overlapping IPs the VRF (or equivalent) should be

All of this are specified in the draft (VRF ID or VLAN ID or subscriber ID).

Thanks
Senthil

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 18 May 2011 04:19:42 -0400

Senthil,

> on choosing the transport (ipfix, netflow etc).

"   This document assumes that the NAT device will use some existing
   framework like IPFIX, Netflow version 9 etc to send the log events to
   the collector.
"

Also, The draft also posit that the format is binary

"   This document assumes that the NAT device will send the events in a
   binary format to an off-box collector to be able to scale to carrier
   grade NAT requirements but the formats (binary or ASCII) itself is
   beyond the scope of this document.
"

And finally reuses Ipfix information IDs.

I'm looking for a draft scrubbed of these protocol specific language which
defines the information model.

Thanks,

Reinaldo

---

From: ssenthil <[email-masked]>
Date: Wed, 18 May 2011 05:26:55 -0400

>    framework like IPFIX, Netflow version 9 etc to send the log events to
Right, and the next sentence is
"  But it is beyond the scope of the document to define
   the framework to be used for logging.  However, the framework should
   support specifying a template that the NAT device will use to send
   its events. "

The point of the above paragraph is that this document does not attempt to
define the framework and the implementation is free to choose its framework.

>    beyond the scope of this document.
[Senthil] You cant use ASCII to log events as it wouldn't scale, so I
assumed that you have binary. Is that restrictive? What other formats do you
think that may be the choices here?

> And finally reuses Ipfix information IDs.

[Senthil] Ah, this maybe the source of confusion. If I remove the IPFIX IDs
would that help your concerns?

Thanks
Senthil

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 18 May 2011 06:05:16 -0400

>    support specifying a template that the NAT device will use to send

'Template' is IPfix terminology. Logging format is outside the scope of
logging document as you propose.

> think that may be the choices here?

That depends on the implementation. Some scale others do not. But Scale is
out of the scope of this document as I understand.

A CGN box is one that has to deal with address sharing, whether for 10 or 1M
subscribers the logging functionality problems are the same.

Therefore let's focus on the information model.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 18 May 2011 15:17:59 -0700

Per 3GPP specification, which is also outlined in
draft-ietf-v6ops-3gpp-eps-01, each subscriber of a 3GPP PDP or EPS
bearer is given a /64 and the user equipment can determine the final
64 host bits (there is no variation from this structure in 3GPP).

I am sure this will be the same case in other access network
architectures, including the use of privacy extensions ... meaning...
the first 64 bits is a unique user and the last 64 bits do not have
any useful meaning in the context of logging, billing, ...  This may
even be the case for DHCP-PD /56s or whatever is given to DSL or Cable
subscribers.

The network operator that is running the NAT may not care about the
final 64 host / subscriber bits and it may be beneficial for multiple
purposes (billing, DPI, business intelligence ...) that the subscriber
/ customer be viewed and treated on only the first 64 bits.  This data
reduction (truncating the last 64 bits) may be beneficial on the
initial log creation and therefore it may be beneficial to add a 64
bit version of "sourceIPv6Address" field

Cameron

---

From: ssenthil <[email-masked]>
Date: Thu, 19 May 2011 23:45:26 -0400

> logging document as you propose.

Template is used in the context of sending the format and fields prior to
the data records, it helps the collector to be able to support multiple
templates. It is not implying usage of IPFIX.