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

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

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