Subject: Re: [BEHAVE] New Version Notification for draft-sivakumar-behave-nat-logging-04.txt

From: Senthil Sivakumar <[email-masked]>
Date: Fri, 15 Jun 2012 14:52:28 -0400

A new version of the logging draft is posted that is focused towards using
IPFIX Information 
Elements for NAT logging. Please review and provide feedback.

Senthil

On 6/14/12 11:44 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-sivakumar-behave-nat-logging-04.txt
>has been successfully submitted by Senthil Sivakumar and posted to the
>IETF repository.
>
>Filename:	 draft-sivakumar-behave-nat-logging
>Revision:	 04
>Title:		 IPFIX Information Elements for logging NAT Events
>Creation date:	 2012-06-14
>WG ID:		 Individual Submission
>Number of pages: 14
>URL:             
>http://www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-logging-04.
>txt
>Status:          
>http://datatracker.ietf.org/doc/draft-sivakumar-behave-nat-logging
>Htmlized:        
>http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-04
>Diff:            
>http://tools.ietf.org/rfcdiff?url2=draft-sivakumar-behave-nat-logging-04
>
>Abstract:
>   Carrier grade NAT (CGN) devices are required to log events like
>   creation and deletion of translations and information about the
>   resources it is managing.  The logs are required in many cases to
>   identify an attacker or a host that was used to launch malicious
>   attacks and/or for various other purposes of accounting.  Since there
>   is no standard way of logging this information, different NAT devices
>   behave differently and hence it is difficult to expect a consistent
>   behavior.  The lack of a consistent way makes it difficult to write
>   the collector applications that would receive this data and process
>   it to present useful information.  This document describes the
>   information that is required to be logged by the NAT devices.
>
>                  
>        
>
>
>The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Jun 2012 16:35:05 -0400

> Elements for NAT logging. Please review and provide feedback.

Looks good!

Question: why did you unite vlan ID and VRF ID? Aren't they orthogonal 
things?

Observation: the term BIB is defined in RFC6146 but only in the context 
of NAT64. Yet this draft uses it in the context of NAT44. I foresee 
problems. For example, it is not clear how a fully symmetric NAT (which 
has no BIB) would use this. Would it only log session events and never 
BIB events? Also, what about NATs that don't track sessions? Would they 
just log BIB events and never session events?

What about NAT46 and NAT66? Are they supported?

Lastly, I see feature overlap between this draft and the MIB draft for 
the addresses exhausted, ports exhausted, and quota exceeded event. Do 
we really want to provide two ways of doing the same thing?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Senthil Sivakumar <[email-masked]>
Date: Mon, 18 Jun 2012 17:02:25 -0400

Thanks for the review.

>Question: why did you unite vlan ID and VRF ID? Aren't they orthogonal

There are two information elements one for VLAN ID and one for VRF ID,
they are listed under Table 1.
In the actual events, I mentioned them as one entity as VlanID/VRF ID, the
reason being either one of them is used
to uniquely identify a private address but not both.

>problems.

Ok, would it help if I change it to NAT44 binding instead of NAT44 BIB?

> For example, it is not clear how a fully symmetric NAT (which

Correct, the NATs that don¹t track the full 5 tuple sessions wont log the
full session.
Similarly the NATs that don¹t have the Binding database but not the
session database will not log the session entry.

>What about NAT46 and NAT66? Are they supported?

NAT46 can be accomodated in the NAT64 record itself, can it not? Wondering
if we need to address NAT66 as it is neither an RFC nor a product.

>we really want to provide two ways of doing the same thing?

I was going through the same thoughts myself. But I have had people asking
these events to be logged.
I think this is where logging is not just for tracking individual users
but crosses into the management domain.
But I also think that people using SNMP wouldn¹t want to log these events.

Thanks
Senthil

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