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

[Julia Renouard <[e-mail]>]

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.

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.

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.


My high level recommendations:
1.       Don't renumber IANA defined enums.  Reasons cited above.
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.
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.
4.       Consider DSLite in your recommendations - what IE's should be used to report a DSLite subscriber?
5.       Make the Port Block Allocation extensions part of the "Create" and "Delete" event templates.
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.
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 )
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.
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.
11.   Look at using natPoolName optionally in more events - I think it will be useful, minimally for errors
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.
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.


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


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

Happy New Year,

Julia Renouard