ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-behave-ipfix-nat-logging-06.txt> (IPFIX Information Elements for logging NAT Events)

2016-02-11 11:48:36


Section 1, second paragraph:

   The IPFIX Information elements that are NAT specific are created with
   NAT terminology.  In order to avoid creating duplicate IE's, IE's
   that are reused if they convey the same meaning.

Capitalise "Elements" and remove the redundant "that" in "that are reused".

The plural of "IE" is "IEs". See section 5 of RFC 7012. Please s/IE's/IE/ throughout the draft.

The draft defines "Information Element (IE)" in section 1 and "Information Elements (IEs)" in section 2. There's no need to repeat (IEs) in sections 2 and 5.2.



Section 2, first paragraph:

   This document details
   the IPFIX Information Elements(IEs) that MUST be logged by a NAT
   device that supports NAT logging using IPFIX.  The document will
   specify the format of the IE's that SHOULD be logged by the NAT
   device and all the optional fields.  The fields specified in this
   document are gleaned from [RFC4787 <https://tools.ietf.org/html/rfc4787>] and 
[RFC5382 <https://tools.ietf.org/html/rfc5382>].


I can't reconcile the "MUST" with the "SHOULD" and the "optional".



Section 5, first paragraph:

   The creation and
   deletion of NAT sessions and bindings are examples of events as it
   results in the resources (addresses and ports) being allocated or
   freed.


s/as it results in the resources/as they result in resources/



Section 5, first paragraph:

   The events can happen either through the processing of data
   packets flowing through the NAT device or through an external entity
   installing policies on the NAT router or as a result of an
   asynchronous event like a timer.


Since this is either/or/or, simply remove the "either".



Section 5, first paragraph:

The list of events are provided inSection 4.1 <https://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-06#section-4.1>.


There is no section 4.1.



Section 5, second paragraph:

   A collector may receive NAT events from multiple CGN devices and MUST
   be able to distinguish between the devices.  Each CGN device should
   have a unique source ID to identify themselves.  The source ID is
   part of the IPFIX template and data exchange.


No; this requires ID synchronisation across devices which is not required for IPFIX. IPFIX uniqueness is guaranteed by the combination of source address, source port, and source ID. The source address provides uniqueness across devices. The source port provides uniqueness when there are multiple exporters within a device (ie, the source addresses are identical). The source ID provides uniqueness when an exporter exports information from multiple unique sources (ie, the source address and source port are identical).

In IPFIX, the source ID is called the Observation Domain ID. See section 3.1 of RFC 7011.



Section 5, third paragraph:

   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.

It's not just about the reliability of the connection. eg the collecting process could restart with no knowledge of the previously exported templates.



Section 5, third paragraph:

   NAT device SHOULD combine as many events as
   possible in a single packet to effectively utilize the network
   bandwidth.


Say "The NAT device ...".



Section 5.2, table 1:

   |        sourceIPv6Address         |     27 |   128 |  Source IPv6  |
   |                                  |        |       |    address    |

Most IPv6 addresses have more than 27 bits. The size and ID values appear to be swapped.



Section 5.3:

        The list can be expanded in the future as necessary.


Define the process for expanding the table, eg Expert Review. Consider putting the table under IANA control to avoid implementers having to refer to a chain of RFCs for the complete definition.



Section 5.3, Table 2: NAT Event ID table

When / where is this table used? It seems to be an extension of the existing natEvent IE, though no mention of this is made in the IANA section and the proposed values constrain the existing "create" and "delete" events to be NAT44 specific.



Section 5.4:

   The Quota exceeded events are generated when the hard limits set by
   the administrator has reached or exceeded.


Say "has been reached or exceeded."

The text should mention that the values are used for the natLimitEvent element in section 8.



Section 5.4:

   The events that can be reported are the Maximum session entries limit
   reached, Maximum BIB entries limit reached, Maximum session/BIB
   entries per user limit reached and maximum subscribers or hosts limit
   reached.


Capitalise "maximum subscribers". The "Maximum fragments pending reassembly" event isn't mentioned.

However there's really no reason to duplicate the information from the table in the preceding description.



Section 5.5:

The text doesn't describe the "Global Address mapping high threshold event" in Table 4.

The text should mention that the values are used for the natThresholdEvent element in section 8.



Section 5.6:

   The following is the template of events that will be logged.  The
   events below are identified at the time of this writing but the set
   of events is extensible.


Describe the process for extending the list of events, eg Expert Review.



Tables 5 - 21:

There's no need to describe the size of each field since that information has already been given in Table 1.
It draws unnecessary attention to the field sizes which should be invariant.



Section 5.6.5:

   The following is a template of the event.  Note that either the NAT
   pool name or the nat pool identifier SHOULD be logged, but not both.


No mention is made of how the NAT pool name could/should be logged (IPFIX IE #284). natPoolID is mandatory in Table 9 which suggests that mention of the NAT pool name should be removed from the text.



Sections 5.6.7.1 and 5.6.7.2:

   The maximum ... is generated when


Say "The maximum ... *event* is generated when" or "This event is generated when".



Section 5.6.7.1:

   when the administratively configured limit is reached.


Define what the limit is, eg "when the administratively configured *NAT session *limit is reached."



Section 5.6.7.2:

   when the administratively configured limit is reached.


Define what the limit is, eg "when the administratively configured *BIB entries *limit is reached."



Section 5.6.7.3:

   when a single user reaches the administratively configured limit.


Define what the limit is, eg "when a single user reaches the administratively configured *IPv4 or IPv6 address* limit."



Section 5.6.8

   This event will be generated


Say, "These events will be generated"



Section 5.6.8

   The threshold reached events are described in the section above.


Please add an xref to the relevant section.



Section 5.6.8.4

   This event is generated when the high is reached


Say, "This event is generated when the high *threshold* is reached"



Section 5.6.8.4

   This is generated only by NAT devices that use a address pooling behavior of 
paired.


Would it be clearer to say, "... that use a paired address pooling behavior." ?



Section 5.6.9

   This binding event happens when the first packet of the first flow
   from a host in the private realm.


Say, "These binding events happen when". The remainder of the sentence seems incomplete?



Section 7:

s/Trammel/Trammell/



Section 9:

   Some management considerations is covered


s/is/are/



Section 9.1:

   An IPFIX collector MUST be able to collect events from multiple NAT
   devices and be able to decipher events based on the sourceID in the
   IPFIX header.


s/sourceID/Observation Domain ID/ per RFC 7011, section 3.1.



Section 11.2:

The References to [RFC5101bis] and [RFC5102bis] should be updated to RFC7011 and RFC7012 respectively.


P.