Re: [IPFIX] NAT logging using IPFIX - Requesting review

Hi Senthil,

On 08/01/2013 09:37 AM, Senthil Sivakumar (ssenthil) wrote:
> I would like the IPFIX WG to review this draft that uses IPFIX to log NAT
> events. 
>
> http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging

I'm a little slow off the blocks on this one, but here is my review of
draft-ietf-behave-ipfix-nat-logging-01.txt.

In Table of Contents "de-allocate" should be "deallocate"
"Acknowledgements" should be "Acknowledgments"

Throughout the draft:  "IE's" is used instead of "IEs"

3.  Scope

 "as stated earlier, this document is not defining IPFIX or NetFlow
v9".  This is the only reference to NetFlow v9 (none earlier or later). 
I would either remove the "or NetFlow v9" or add some more about to the
intended compatibility with NetFlow v9.  Nothing jumped out at me as nto
NetFlow v9 compatible, but there are differences.

I'm not sure that this text...

  "This would mean
   that the NAT device will specify the template that it is going to use
   for each of the events.  The templates can be of varying length and
   there could be multiple templates that a NAT device could use to log
   the events."

belongs in the Scope.  In fact there are various bits of IPFIX specific
advice scattered through the draft.  I would prefer to see this draft
focus exclusively on the IEs needed and example templates.  I would change

   "The implementation details of the collector application is beyond the
   scope of this document."

to something like

   "The implementation details of the collector application and exporter
function is beyond the scope of this document."


5.  Event based logging

I would delete this text

" A NAT device MAY log these events to multiple collectors
   if redundancy is required.  The network administrator will specify
   the collectors to which the log records are to be sent."

and this text

   "Prior to logging any events, the NAT device MUST send the template of
   the record to the collector to advertise the format of the data
   record that it is using to send the events.  The templates can be
   exchanged as frequently as required given the reliability of the
   connection.  There SHOULD be a configurable timer for controlling the
   template refresh.  NAT device SHOULD combine as many events as
   possible in a single packet to effectively utilize the network
   bandwidth."

The above seem out of scope for specifying IEs and templates.


5.2.  Information Elements

timeStamp is used in several places and specified as IE 323.  There
isn't a single IPFIX timeStamp IE, but several depending on your
granularity requirements.  IE 323 is named
"observationTimeMilliseconds".  Also available are:

322    observationTimeSeconds
323    observationTimeMilliseconds
324    observationTimeMicroseconds
325    observationTimeNanoseconds

I would remove the columns for "Size (bits)" and maybe "Description" and
refer people to
http://www.iana.org/assignments/ipfix.
If you feel you need to keep size it would be more consistent with other
IPFIX documents to specify dataType (eg unsigned64 vs 64 and ipv6Address
vs 128).

If you keep the Description "occured" in the timeStamp Description
should be "occurred"

The IE name for "vlanID" is actually "vlanId"

sourceIPv6Address has the IE in the bits column and bits in the IE column

postNATSourceIPv6Address "addresss" should be "address"

5.3.  Definition of NAT Events

Is this the definition for natEvent(230)?  This doesn't match my
understanding of what is currently defined.

Currently
1 - Create event.
2 - Delete event.
3 - Pool exhausted.

None of these specify NAT44.  My understanding was that these events are
equally applicable to NAT other than just NAT44 and the collector would
infer the type of NAT from the type of addresses being sent.  For
example If the template includes a v6 source and a v4 destination the
Create event is probably for a 64 NAT.

So it isn't clear to me that you need

                   |   NAT64 Session create   |      4 |
                   |   NAT64 Session delete   |      5 |

Also I think

                   |     NAT44 BIB create     |      6 |
                   |     NAT44 BIB delete     |      7 |
                   |     NAT64 BIB create     |      8 |
                   |     NAT64 BIB delete     |      9 |

Can be collapsed to just

4 - BIB create.
5  - BIB BIB create.

The last event, "Port block de-allocation", should be "Port block
deallocation"


5.4.  Quota exceeded - Sub Event types

Maybe I missed something, but I don't see an IE defined to send this
information.


5.5.  Templates for NAT Events

I would drop the size column from the tables in this section too.


5.5.2.  NAT64 create and delete session event

"This event will be generated when a NAT64 session is created.  The
   following is a template of the event."

Should be

   "This event will be generated when a NAT64 session is created or
   deleted.  The template will be the same, the natEvent will indicate
   whether it is a create or a delete event.  The following is a
   template of the event."

I wonder if it is really necessary to duplicate everything between 5.5.1
and 5.5.2 when the only real difference is the address types.  Same
comment for 5.5.3 and 5.5.4.

5.5.3.  NAT44 BIB create and delete event

"This event will be generated when a NAT44 Bind entry is created." 
Needs an "or deleted".


5.5.4.  NAT64 BIB create and delete event

"This event will be generated when a NAT64 Bind entry is created."
Needs an "or deleted".

5.5.5.  Addresses Exhausted event

"wont" should be "won't" in "NAT device wont be able to create"

5.5.6.  Ports Exhausted event

I'm not a NAT/IPv6 expert so I could easily be missing something here,
but is this really only an IPv4 event?


7.  Acknowledgements
should be
7.  Acknowledgments


8.  IANA Considerations

   Currently "There are no IANA considerations for this document."

Should include update of natEvent with additional values and creation of
Quota exceeded - Sub Event.

-Andrew

>
> This is a behave working group draft. Your feedback is greatly appreciated.
>
> Thanks
> Senthil
>
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix