Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05

["Senthil Sivakumar (ssenthil)" <[e-mail]>]

Hi Tina,
The focus of the logging draft as it exists is not to reduce the logging, it is a framework document that can define templates for logging in a generic way.
As it says in  section 3 "The optimization of logging the NAT events are left to the implementation and are beyond the scope of this document.".
We don’t any overlap between these two documents that requires converging/merging.

Thanks
Senthil

From: Tina TSOU <[e-mail]<mailto:[e-mail]>>
Date: Friday, January 4, 2013 11:41 PM
To: Senthil Sivakumar <[e-mail]<mailto:[e-mail]>>
Cc: Julia Renouard <[e-mail]<mailto:[e-mail]>>, "Reinaldo Penno (repenno)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05

Dear Senthil, Reinaldo et al,
Draft-sivakumar does describe dynamically assign port range and take logs based on port range, which overlaps much with draft-tsou-behave-natx4-log-reduction.

http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05#section-4.4.9 describes allocating and retrieving port range, but it is not clear whether one user can have multiple port range, or only one.

Though the focus of this draft is not how to allocate port range, only mentions what content in the recorded information.
This draft currently only supports continuous port range, not non-continuous one.

So I propose these two drafts converge.

Thank you,
Tina

On Jan 4, 2013, at 6:49 AM, "Senthil Sivakumar (ssenthil)" <[e-mail]<mailto:[e-mail]>> wrote:



From: Julia Renouard <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, January 2, 2013 9:05 PM
To: Senthil Sivakumar <[e-mail]<mailto:[e-mail]>>, "Reinaldo Penno (repenno)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Comments on draft-sivakumar-behave-nat-logging-05

Hi Senthil – Nice fast turn-around.  So part of my confusion here appears to be derived from your opening sentence in the Abstract and Scope sections:   “This document provides the information model to be used for logging the Carrier Grade NAT (CGN) events.”   So you might want to clarify the scope as well if this is intended to be broader than CGN.  :)  My apologies that I did not review the history of this draft.  I started with this for review – a bit in a vacuum I admit.

[Senthil] Right, the sentence after the first one says "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.", which is not specific to CGN. But I agree, it might have been misleading. I will do some wordsmithing to clarify this better.

A follow up thought, if this is intended to be for all NAT types, including generic NAT and CGN, not paying attention to minimizing logging and the bandwidth and data constraints of the CGN deployments will end up making most CGN devices to only be partially compliant if the recommendations laid out here remain a SHOULD or do not take this need into account.  We will simply have to use it as high-level guidance and take our own path because minimizing logging is a requirement for us.  Even so, I think it will still be useful to identify the common use-cases for logging.  This helps better review if the recommendations you are making achieve those goals or not.

[Senthil] The templates and the framework are generic enough that would be applicable to both. For the log reduction, there are already a couple of drafts that talks about ways to do that.

On the question of the generic vs specific natEvent enumerations, I actually feel the generic is more extensible, but yes, I agree – broader WG opinions should be sought and to be honest I have not compared it with other IE’s for consistency nor looked at IPFIX collector implementations.  My concern is as much from a “best practice” of data hiding – where events are generic and type is part of data.  This facilitates extensibility and future proofing implementations.  The example of the error enumeration is a good one.  As a collector, I can implement to recognize a generic  “Translation error” event – and I don’t need to update my software for every new error type that comes along.  I know I will catch it.  I may not know what type of error but I will know an error occurred.  As for the generic NAT events vs. specific type-encoded events, yes I understand the goal of having the nat type.  You could provide the additional natType IE in the template but, as you say, that is an additional byte.  However IMHO the value of extensibility outweighs this.  In order to add NAT66, for example, you now need to extend this yet again.    Not having implemented an IPFIX collector I cannot speak to whether this addition of the NAT type actually resolves any ambiguity that the different templates would not.  (sourceIPv6Address vs. IPv4).

I’d have to look back in the threads for the feedback on DS-Lite to understand the concerns wrt this draft, but as an implementer it is something I have to solve.  I don’t think it requires any new types.  But I think it would be useful to offer template guidance.  For us, we were intending simply to use a sourceIPv6Address IE (consistent with Section 4 in behave-lsn-requirements).  Optionally we may also include a sourceIPv4Address if the customer desired.  Again, I don’t think it needs its own IE’s or types, just template guidance and how this will be interpreted commonly by collectors.  Just a thought…

Thanks again – we look forward to the next round.  I appreciate your work here,
Julia

Thanks
Senthil

From: Senthil Sivakumar (ssenthil) [mailto:[e-mail]]
Sent: Wednesday, January 02, 2013 4:14 PM
To: Julia Renouard; Reinaldo Penno (repenno); [e-mail]<mailto:[e-mail]>
Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05

Hi Julia,
Thanks for the comments. Please see inline.

From: Julia Renouard <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, January 2, 2013 5:28 PM
To: "Reinaldo Penno (repenno)" <[e-mail]<mailto:[e-mail]>>, Senthil Sivakumar <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Comments on draft-sivakumar-behave-nat-logging-05

Hi Reinaldo & Senthil –

Thank you for your work here.  I know this has been through a few iterations .  I do think this is needed minimally as guidance.   This was the only thing we found, save for section 4 in behave-lsn-requirements that gave guidance on CGN logging.  And your justification is spot-on.   Now for feedback…

Summary:
First, we are very concerned about the re-enumeration of natEvent values in section 4.2.  It is not good practice and is disruptive to implementers to re-enumerate published values.  Also the values created here are too specific and make this not-easily extended.    The only exception I might make here is to change the existing "Pool Exhausted" value to be "Translation Failure" or simply add a new enum for this.  I think generic events are better than specific.  More on this below.

[Senthil] I assume you mean the IPFIX IANA assigned values for natEvents. You are right, there is an inconsistency between the two. As you pointed out, the create and delete event is consistent with the IPFIX values, we need to add the poolExhausted value in the draft or create a new value for it.  We will do it as part of the next rev.

I would like to see this draft reference and be consistent with draft-ietf-behave-lsn-requirements-x which does describe, in section 4, logging requirements for a CGN.  I think this document needs align with the logging requirements here in the overall goals and constraints.  Namely, the primary goal for NAT logging is to enable the ability to identify a subscriber - often for legal reasons.  The constraint that we need to be mindful of is logging resource consumption.  Many CGN features are specifically designed to minimize log size while still maintaining the ability to identify subscribers - Port block allocation for example.

[Senthil] This document is not just for CGN logging, it is a generic NAT logging document that can be used also for satisfying CGN logging requirements. As mentioned in the scope, the optimization of log events (size, the way you pack the records etc) is not within the scope of this document. There are many other documents that provide solutions for that. The main purpose of this document is to provide a framework and a template to log NAT events – that both the NAT vendors and the collector vendors can use to interoperate.

CGN logging for the purposes of identifying subscribers and with the goal of minimizing data consumption, needs to focus on the NAT translations (bindings) and be as minimalistic as possible.  Flow logging or session logging has a different purpose - statistical, data usage analysis, quality analysis, security, billing…  There may be some overlap of use-cases but this document doesn't really speak to them.  It might be interesting to look at typical/traditional NetFlow/IPFIX Flow logging and see how that might be different for a NAT.   But there are at least 2 different use-cases - if this document wants to address both, I think it would be useful to distinguish them.  But flow/session logging needs to be discrete because administrators may only choose translation logging for data conservation purposes.  It seems to me that your session create/delete events fall into this camp, although I’m interested in your intent here.  Minimally I’d be interested in a comparison.

[Senthil] Just to re-iterate, the focus of the draft is generic NAT logging – not just CGN. The NAT templates defined in the draft is generic enough to cover both CGN and non-CGN NAT logging. I am not really sure I understand the gist of the above paragraph, but flow logging is being used for data retention purposes. Again our intention here is have a generic logging framework.


My high level recommendations:
1.       Don't renumber IANA defined enums.  Reasons cited above.

[Senthil] Ok. But a lot of what is defined here is what went on to become IANA values, but your point is well taken, we will get rid of inconsistencies.

2.       Keep high level events generic.  This makes them more extensible.  "Create", "Delete" and "Translation Failure" - with more data as additional (optional) IE's.  For example, keeping the "error" event generic allows collectors to universally identify an error, even as more error types are created.
[Senthil] The problem is if we have a simple create, delete, we wont be able to distinguish what kind of an nat this is – nat44, nat64 etc. For us to add additional data, that would cause us to have another byte. In this case, we can have a max of 256 types (with 8 bits) and hence make sense to present the information in one shot. I am open to suggestions here but would like some WG guidance.

3.       Be careful about error logging recommendations.  I would set these as MAY with comments about limiting how often these are emitted in a pool exhaustion case so as not to DoS the source or target system.
[Senthil] Agreed.

4.       Consider DSLite in your recommendations - what IE's should be used to report a DSLite subscriber?

[Senthil] We had DS lite in earlier revision of the draft in -03. But the WG wanted us to keep it specifically to NAT, so the latest versions got rid of them.

5.       Make the Port Block Allocation extensions part of the "Create" and "Delete" event templates.
[Senthil] Ok.
6.       Call out specifically which IE's are new.  Section 7 is not complete or accurate.  portRange* ID's have been defined.  You also have IE's identified which do not exist and are not called out in section 7.
[Senthil] Ok.
7.       Section 4 - Event based Logging:  "Each of these events SHOULD be logged, unless they are administratively prohibited" - This is a problematic recommendation and is contrary to the need to minimize logging (i.e. logging every session )
[Senthil] As I clarified above, minimizing logging is not a goal of this draft.

8.       Bring this into alignment with draft-behave-lsn-requirements.   E.g. REQ-12. Destination addresses SHOULD NOT be logged.  That said, a mapping event MAY have a destination address if administrator requires it.  In which case I would recommend only 1 IE - destinationIPxAddress or postNATDestinationIPvxAddress - both seems redundant.
[Senthil] I think we can add some text around this, that if the CGN is running, then destination address should not be logged.

9.       Separate out session logging from translation logging.  Session logging bloats the data set and is unnecessary just for identifying subscribers


10.   Describe the difference between session logging and BIB(translation) logging and when to use them.  IMHO session logging looks a lot more like flow logging.  I'd be interested in a description of the differences and a separate of the two cases.  Perhaps flow logging for NAT's is a separate use-case.
[Senthil] As explained above, for 9 & 10, this is a generic draft.
11.   Look at using natPoolName optionally in more events - I think it will be useful, minimally for errors

[Senthil] Ok.
12.   Can we find an IE to send a "subscriber identity"?  I'm wondering about #371, "userName" - for a mobile service provider this might actually be an IMSI or IMEI numbers.  This would be optional.
[Senthil] I will check, the last time I checked there were a couple of fields that could be used.

13.   Be mindful of the need for data conservation and to minimize logging in your MUST and SHOULD requirements.  MUST and SHOULD requirements should be minimalistic to achieve the base use-case and nothing more.  E.g. look to the data elements identified in behave-lsn-requirements.  But ideally it also gives guidance on some typical use-cases and how to achieve them.

[Senthil] Minimizing the logging is not the goal of this draft.


One more nit:   [NAT-EVENT-LOG-IANA] - this link does not exist.  You should update this to be the IANA IPFIX IE registry.

[Senthil] Ok, thanks.


Thanks again for this.  I hope this feedback is helpful.  We look forward to the next draft.

[Senthil] Thanks for the helpful comments. Will incorporate the relevant ones.

Senthil

Happy New Year,

Julia Renouard