Re: [BEHAVE] AD Evaluation of draft-ietf-behave-ipfix-nat-logging-03

[Spencer Dawkins <[e-mail]>]

Hi, Senthil,

I'm just checking - are you planning to submit a update before the 
cutoff next Friday?

Thanks,

Spencer

On 05/23/2014 04:05 PM, Spencer Dawkins wrote:
>
> On 05/02/2014 02:20 PM, Senthil Sivakumar (ssenthil) wrote:
>> Hi Spencer,
>> Thanks for the thorough review.
>> Please see inline for [Senthil]. If you agree, I will submit another 
>> version fixing all the issues raised and agreed upon. I will wait for 
>> your response.
>
> Hi, Senthil,
>
> Thanks for being responsive!
>
> Just as a high-order bit, many of the questions I asked are whether 
> the draft uses "required" to mean "this is the way it works" - there's 
> a difference between "the sender transmits a log" and "the sender is 
> required to transmit a log". Does that make sense?
>
> Ths draft says it uses requirements language as per RFC 2119, and RFC 
> 2119 says
>
> 6. Guidance in the use of these Imperatives
>
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions) For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
>
> It's also worth mentioning that RFC 2119 is silent on case for 
> requirements language, your requirements terminology section only 
> shows upper case examples, and most of the cases I'm asking about are 
> in lower case, which makes it less clear whether you intend "require" 
> to be an RFC 2119 requirement word or not. This is a continuing source 
> of controversy in the IETF, especially during cross-area review - my 
> suggestion is that you either change the requirements language 
> statement to include a statement about whether lower-case versions are 
> intended as requirements language, or don't use the lower-case terms 
> in the document.
>
> I'll try to be clear in my detailed comments, but that's often what 
> I'm trying to get at.
>
>> Thanks
>> Senthil
>>
>> From: Spencer Dawkins <[e-mail] 
>> <mailto:[e-mail]>>
>> Date: Thursday, May 1, 2014 4:25 PM
>> To: "[e-mail] 
>> <mailto:[e-mail]>" 
>> <[e-mail] 
>> <mailto:[e-mail]>>
>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] 
>> <mailto:[e-mail]>>
>> Subject: AD Evaluation of draft-ietf-behave-ipfix-nat-logging-03
>> Resent-From: <[e-mail] 
>> <mailto:[e-mail]>>
>> Resent-To: <[e-mail] <mailto:[e-mail]>>, Senthil 
>> Sivakumar <[e-mail] <mailto:[e-mail]>>
>> Resent-Date: Thursday, May 1, 2014 4:26 PM
>>
>> Dear draft-ietf-behave-ipfix-nat-logging Authors,
>>
>> I've completed my AD evaluation for this draft. I found some things 
>> I'd like to see changed before proceeding, but most are editorial. 
>> Please take a look, and let me know what you think.
>>
>> My notes follow ... you should be able to find my questions and 
>> comments by searching for "SD:".
>>
>> Thanks,
>>
>> Spencer
>>
>> In the Abstract
>>
>>    NAT devices are required to log events like creation and deletion of
>>                    ^^^^^^^^
>> SD: Is this required, like, legally required, or ? Is it more like 
>> "Operators need NAT devices to log events ..."?
>> [Senthil] : It is the later, the network operators require the NAT 
>> devices to be able to log events.
>
> We don't usually include requirements language in the Abstract (that 
> happens later, which is fine in the document body).
>
> The longer I look at this, the more I think it's something like 
> "Operators expect NAT devices to log events".
>
>>
>>    translations and information about the resources it is managing.  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.  Since there is no standard way of logging
>>    this information, different NAT devices behave differently and hence
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> SD: Is this "different NAT devices log this information differently"?
>> [Senthil] Correct, as the sentence says, "Since there is no standard 
>> way…", each NAT device logs information in its own proprietary format.
>
> I'm just trying to make sure the reader understands what you mean by 
> "behave differently" - NAT devices also behave differently when 
> NATting.  I had to guess at the meaning. Maybe everyone else will 
> understand?
>
>>    it is difficult to expect a consistent behavior.  The lack of a
>>    consistent way makes it difficult to write the collector applications
>>    that would receive this data and process it to present useful
>>    information.  This document describes the information that is
>>    required to be logged by the NAT devices.
>>    ^^^^^^^^^^^^^^^^^^^^^^^^
>> SD: Same as previous question - is this "logged by"?
>>
>> [Senthil] If a NAT device is logging events, these are the 
>> requirements that a NAT device should adhere to.
>
> I know this seems tedious, but I'm not able to map what you provided 
> as explanation onto the text you're explaining. What I'm seeing in the 
> text is
>
> A NAT MUST log this information
>
> and what I'm seeing in your explanation is
>
> IF a NAT is is logging information, here's how the NAT SHOULD log 
> information.
>
> I'm guessing that what you're saying is really "this document 
> describes the information that logging NAT devices produce".
>
> This doesn't matter yet (you're still in the abstract, which shouldn't 
> be providing requirements anyway), but in the body of the document, it 
> needs to be clear.
>
>> 2.  Introduction
>>
>>    The IPFIX Protocol [RFC5101bis] defines a generic push mechanism for
>>    exporting information and events.  The IPFIX Information Model
>>    [IPFIX-IANA] defines a set of standard Information Elements (IEs)
>>    which can be carried by the IPFIX protocol.  This document details
>>    the IPFIX Information Elements(IEs) that are required for logging by
>>    a NAT device.  The document will specify the format of the IE's that
>>    are required to be logged by the NAT device and all the optional
>>        ^^^^^^^^^^^^^^^^^^^^^
>> SD: Now that we're in the document body, if this is required, 
>> shouldn't there be a reference to where the requirements are stated?
>> [Senthil] This is the document that is specifying those requirements. 
>> Do you have any other suggestions of wording instead of "required 
>> by", would it be fine if I change the sentence from
>> "required to be logged" to "SHOULD be logged"?
>
> Sorry, my first set of comments was bogus. What triggered my comments 
> was the use of lower-case terms from RFC 2119 (see my explanation above).
>
> This could be "are REQUIRED" (the RFC 2119 requirements language you 
> said you're using), or "are required" (if you change your paragraph 
> about requirements language to say that case doesn't matter).
>
> But "REQUIRED" is "MUST", so changing to "SHOULD" would be a change in 
> your intended meaning.
>
>>
>>    This document and [I-D.behave-syslog-nat-logging] are provided in
>>    order to standardize the events and parameters to be recorded, using
>>    IPFIX [RFC5101bis] and SYSLOG [RFC5424]respectively.
>
> I'm sorry I missed this question the first time. Is there a 
> relationship with the MIB revision?
>
>> 3.  Scope
>>
>>    This document provides the information model to be used for logging
>>    the NAT devices including Carrier Grade NAT (CGN) events.  This
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> SD: This sentence seems somewhat turned around - "logging events", 
>> not "logging the NAT devices".
>> [Senthil] Agree, I will change this to "logging the NAT events".
>
> Thanks.
>
>>    document focuses exclusively on the specification of IPFIX IE's.
>>    This document does not provide guidance on the transport protocol
>>    like TCP, UDP or SCTP that is to be used to log NAT events.  The log
>>    events SHOULD NOT be lost but the choice of the actual transport
>>    protocol is beyond the scope of this document.
>>
>> SD: I'm not understanding why this last sentence is needed, 
>> especially with a normative requirement for what you do when you are 
>> doing something outside the scope of the document ...
>> [Senthil] Are you objecting to the second part of the last sentence 
>> "the choice of actual transport…", I think the requirement is that 
>> the LOG events should not be lost is valid.
>
> I'm sorry, my question wasn't clear. What I intended to say was that I 
> was confused because the text said "not providing guidance on the 
> choice of a transport protocol", but then provided a requirement about 
> the implications of that choice (using a SHOULD).
>
> So let me try to be clearer. I think what you're saying is
>
> - you can use any transport protocol, but you SHOULDn't lose anything
>
> I'm thinking this may be underspecified, although I don't know what 
> IPFIX usually expects from transport protocols, so please be patient.
>
> First, I'm confused by the SHOULD with no qualification. When is it OK 
> to lose LOG events?
>
> Second, you're not giving guidance on selecting a transport protocol, 
> but you are giving guidance about expecting a reliable data channel, 
> whether MUST be reliable or SHOULD be reliable. Are there other 
> transport characteristics that you expect? For instance, is in-order 
> delivery assumed? Is duplicate detection by IPFIX assumed (if a log 
> arrives twice, does IPFIX notice)?
>
> Third, are IPFIX implementations so transport protocol-agnostic that 
> if my NAT device decides to to send logs using SCTP with partial 
> reliability, I should expect that to work with any collector that 
> implements this specification?
>
> It happens that I co-chaired MEDIACTRL when the specification said 
> "TCP or SCTP", and got feedback during AD evaluation that if we didn't 
> pick a mandatory to implement transport protocol, that wouldn't 
> guarantee interoperation between two standard-conforming devices.
>
>>
>>    The existing IANA IPFIX IEs registry [IPFIX-IANA] already has
>>    assignments for many NAT logging events.  For convenience, this
>>    document uses those same IEs.  However, as stated earlier, this
>>    document is not defining IPFIX or NetFlow v9 as the framework for
>>    logging.  Rather, the information contained in these elements is
>>
>> SD: I got lost on "these elements" - is that "the elements in the 
>> existing registry"
>> [Senthil] Yes. How about "Rather, the information elements as defined 
>> in the IPFIX-IANA registry is within the scope of this document"?
>
> I think that's "are within", but yes, that works. Thanks.
>
>>    within the scope of this document.
>>
>>    This document assumes that the NAT device will use the existing IPFIX
>>    framework to send the log events to the collector.  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.
>>
>>    The implementation details of the collector application is beyond the
>>    scope of this document.
>>
>>    The optimization of logging the NAT events are left to the
>>                                               ^^^
>>    implementation and are beyond the scope of this document.
>>                       ^^^
>> SD: It's a nit, but those "are"s should be "is"s.
>> [Senthil] Ok.
>
> Thanks.
>
>> 4.  Applicability
>>
>>    NAT logging based on IPFIX uses binary encoding and hence is very
>>    efficient.  IPFIX based logging is recommended for environments where
>>    a high volume of logging is required, for example, where per-flow
>>    logging is needed.  However, IPFIX based logging requires a collector
>>    that processes the binary data and requires a network management
>>    application that converts this binary data to a human readable
>>    format.
>>
>> 5.  Event based logging
>>
>>    An event in a NAT device can be viewed as a happening as it relates
>>                                                ^^^^^^^^^
>> SD: Is this "a state transition"? I found "a happening" somewhat odd.
>> [Senthil] Yes, I can rephrase this as "viewed as a state transition 
>> as it relates to" or "viewed as an action as it relates to", if that 
>> is ok.
>
> If "a state transition" is correct, I'd prefer that (if it's correct 
> :-) ).
>
>>    to the management of NAT resources.  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.  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.  The list of events are provided in Section 4.1.  Each
>>    of these events SHOULD be logged, unless they are administratively
>>    prohibited.  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.
>>
>>    A collector may receive NAT events from multiple CGN devices and
>>    should be able to distinguish between the devices.  Each CGN device
>>    ^^^^^^
>> SD: I'm not sure why this isn't a SHOULD, or even a MUST.
>>
>>    should have a unique source ID to identify themselves. The source ID
>>    ^^^^^^
>> SD: Again, I'm not sure why this isn't a SHOULD, or even a MUST.
>>
>> [Senthil] Well, this is NOT a statement for a NAT device, instead it 
>> is a collector that some application writer will
>> develop.
>
> Don't you think you can levy requirements about that on the collector? 
> I don't understand.
>
> But beyond that, what I THINK the text is saying, is that multiple CGN 
> devices can ("may") send to a single collector, that none of the CDN 
> devices have to have a unique source ID to identify themselves 
> ("should", but not "must"), and that the collector is still expected 
> to be able to distinguish among logs coming from multiple CGNs ("should").
>
> Am I misreading this?
>
> If not, do you think that works?
>
>>    is part of the IPFIX template and data exchange.
>>
>>    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.
>>
>> 5.1.  Logging of destination information
>>
>>    Logging of destination information in a NAT event has been discussed
>>    in [RFC6302] and [RFC6888].  Logging of destination information
>>    increases the size of each record and increases the need for storage
>>    considerably.  It increases the number of log events generated
>>    because when the same user connects to a different destination, it
>>    results in a log record per destination address.  Logging of
>>    destination information also results in the loss of privacy and hence
>>    should be done with caution.  However, this draft provides the
>>    necessary fields to log the destination information in cases where
>>    they are required to be logged.
>>
>> 5.2.  Information Elements
>>
>>    The templates could contain a subset of the Information Elements(IEs)
>>    shown in Table 1 depending upon the event being logged. For example
>>    a NAT44 session creation template record will contain,
>>                                             ^^^^
>> SD: Is this the only possible NAT44 template? If so, fine, but if 
>> not, perhaps "could contain", or "typically contains"?
>>
>> [Senthil] Yes, this is all the information that a NAT44 need to 
>> export as it is the least common denominator.
>
> My question is whether any other IEs might be added in the future, I 
> think. If not, "will" is OK, but "MUST" would be clearer.
>
>>    {sourceIPv4Adress, postNATSourceIPv4Address, destinationIpv4Address,
>>    postNATDestinationIPv4Address, sourceTransportPort,
>>    postNAPTSourceTransportPort, destinationTransportPort,
>>    postNAPTDestTransportPort, internalAddressRealm, natEvent, timeStamp}
>>
>>    An example of the actual event data record is shown below - in a
>>    readable form
>>
>>    {192.168.16.1, 201.1.1.100, 207.85.231.104, 207.85.231.104, 14800,
>>    1024, 80, 80, 0, 1, 09:20:10:789}
>>
>>    A single NAT device could be exporting multiple templates and the
>>    collector should support receiving multiple templates from the same
>>    source.observationTimeMilliseconds
>>
>>    The following is the table of all the IE's that a CGN device would
>>    need to export the events.  The formats of the IE's and the IPFIX IDs
>>    are listed below.
>>
>> SD: I noticed that some IEs below have a name that matches 
>> http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-elements 
>> for the same IPFIX ID number, but others do not ("timeStamp" here 
>> doesn't match "observationTimeMilliseconds", but both are IPFIX ID 
>> 323, aren't they?) Is there a reason to use names that don't match 
>> the IANA registry?
>>
>> [Senthil] Good question, in case of timeStamp, I was looking for 
>> something that already existed in the IPFIX registry rather than 
>> asking for a new one. However, the terminology of 
>> "observationTimeMilliseconds" is not the terminology that we use in 
>> the NAT drafts/rfc's. So I am open to suggestions here. I can clarify 
>> in the description that is called observationTimeMilliSeconds". The 
>> other field is internalAddressRealm and externalAddresRealm, this is 
>> the terminology that we used in NAT MIB, syslog and other documents. 
>> However, when we defined the IPFIX IE, we didn’t stick to the same 
>> terminology, so I don’t know if I can go and ask the IPFIX IANA to 
>> change the name. Again I am open to suggestions, the dillema is 
>> whether I should stick to the existing IPFIX IANA terminology or the 
>> behave documents terminology.
>
> I'm way out of my depth on this one (sorry!).
>
> Fortunately, the next stop for an AD-sponsored IPFIX specification is 
> the IPFIX review team. Could you just add a note pointing this 
> question out, and asking if they have any suggestions?
>
>> +----------------------------------+--------+-------+---------------+
>>    |            Field Name            |   Size |  IANA |  Description  |
>>    |                                  | (bits) | IPFIX |               |
>>    |                                  |        |    ID |               |
>> +----------------------------------+--------+-------+---------------+
>>    |            timeStamp             |     64 |   323 |  System Time  |
>>    |                                  |        | |    when the   |
>>    |                                  |        | |     event     |
>>    |                                  |        | |    occured.   |
>>    |          natInstanceId           |     32 |   TBD |  NAT Instance |
>>    |                                  |        | |   Identifier  |
>>    |              vlanID              |     16 |    58 |   VLAN ID in  |
>>    |                                  |        | |    case of    |
>>    |                                  |        | |  overlapping  |
>>    |                                  |        | |    networks   |
>>    |           ingressVRFID           |     32 |   234 |   VRF ID in   |
>>    |                                  |        | |    case of    |
>>    |                                  |        | |  overlapping  |
>>    |                                  |        | |    networks   |
>>    |        sourceIPv4Address         |     32 |     8 |  Source IPv4  |
>>    |                                  |        | |    Address    |
>>    |     postNATSourceIPv4Address     |     32 |   225 |   Translated  |
>>    |                                  |        | |  Source IPv4  |
>>    |                                  |        | |    Address    |
>>    |        protocolIdentifier        |      8 |     4 |   Transport   |
>>    |                                  |        | |    protocol   |
>>    |       sourceTransportPort        |     16 |     7 |  Source Port  |
>>    |   postNAPTsourceTransportPort    |     16 |   227 |   Translated  |
>>    |                                  |        | |  Source port  |
>>    |      destinationIPv4Address      |     32 |    12 |  Destination  |
>>    |                                  |        | |  IPv4 Address |
>>    |  postNATDestinationIPv4Address   |     32 |   226 |   Translated  |
>>    |                                  |        | |      IPv4     |
>>    |                                  |        | |  destination  |
>>    |                                  |        | |    address    |
>>    |     destinationTransportPort     |     16 |    11 |  Destination  |
>>    |                                  |        | |      port     |
>>    | postNAPTdestinationTransportPort |     16 |   228 |   Translated  |
>>    |                                  |        | |  Destination  |
>>    |                                  |        | |      port     |
>>    |        sourceIPv6Address         |     27 |   128 |  Source IPv6  |
>>    |                                  |        | |    address    |
>>    |      destinationIPv6Address      |    128 |    28 |  Destination  |
>>    |                                  |        | |  IPv6 address |
>>    |     postNATSourceIPv6Address     |    128 |   281 |   Translated  |
>>    |                                  |        | |  source IPv6  |
>>    |                                  |        | |    addresss   |
>>    |  postNATDestinationIPv6Address   |    128 |   282 |   Translated  |
>>    |                                  |        | |  Destination  |
>>    |                                  |        | |  IPv6 address |
>>    |       internalAddressRealm       |      8 |   229 |     Source    |
>>    |                                  |        |       | Address Realm |
>>    |       externalAddressRealm       |      8 |   TBD |  Destination  |
>>    |                                  |        |       | Address Realm |
>>    |             natEvent             |      8 |   230 | Type of Event |
>>    |          portRangeStart          |     16 |   361 |   Allocated   |
>>    |                                  |        | |   port block  |
>>    |                                  |        | |     start     |
>>    |           portRangeEnd           |     16 |   362 |   Allocated   |
>>    |                                  |        | |   Port block  |
>>    |                                  |        | |      end      |
>>    |            natPoolID             |     32 |   283 |    NAT pool   |
>>    |                                  |        | |   Identifier  |
>>    |          natLimitEvent           |     32 |   TBD |  Limit event  |
>>    |                                  |        | |   identifier  |
>> +----------------------------------+--------+-------+---------------+
>>
>>                       Table 1: Template format Table
>>
>> 5.3.  Definition of NAT Events
>>
>>    The following are the list of NAT events and the proposed event
>>    values.  The list can be expanded in the future as necessary.  The
>>    data record will have the corresponding natEvent value to identify
>>    the event that is being logged.
>>
>>                    +--------------------------+--------+
>>                    |        Event Name        | Values |
>>                    +--------------------------+--------+
>>                    |   NAT44 Session create   |      1 |
>>                    |   NAT44 Session delete   |      2 |
>>                    | NAT Addresses exhausted  |      3 |
>>                    |   NAT64 Session create   |      4 |
>>                    |   NAT64 Session delete   |      5 |
>>                    |     NAT44 BIB create     |      6 |
>>                    |     NAT44 BIB delete     |      7 |
>>                    |     NAT64 BIB create     |      8 |
>>                    |     NAT64 BIB delete     |      9 |
>>                    |   NAT ports exhausted    |     10 |
>>                    |      Quota exceeded      |     11 |
>>                    |  Address binding create  |     12 |
>>                    |  Address binding delete  |     13 |
>>                    |  Port block allocation   |     14 |
>>                    | Port block de-allocation |     15 |
>>                    |    Threshold reached     |     16 |
>>                    +--------------------------+--------+
>>
>>                         Table 2: NAT Event ID table
>>
>> 5.4.  Quota exceeded Event types
>>
>>    The following table shows the sub event types for the Quota exceeded
>>    or limits reached event.  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.
>>
>> +---------------------------------------+--------+
>>             |       Quota Exceeded Event Name       | Values |
>> +---------------------------------------+--------+
>>             |        Maximum Session entries |      1 |
>>             |          Maximum BIB entries |      2 |
>>             |        Maximum entries per user |      3 |
>>             |  Maximum active hosts or subscribers |      4 |
>>             |  Maximum fragments pending reassembly |      5 |
>> +---------------------------------------+--------+
>>
>>                     Table 3: Quota Exceeded event table
>>
>> 5.5.  Threshold reached Event types
>>
>>    The following table shows the sub event types for the threshold
>>    reached event.  The administrator can configure the thresholds and
>>    whenever the threshold is reached or exceeded, the corresponding
>>    events are generated.
>>
>>    The address pool high threshold event will be reported when the
>>    address pool reaches a high water mark as defined by the operator.
>>    This will sever as an indication that the operator might have to add
>>    more addresses to the pool or an indication that the subsequent users
>>    may be denied NAT translation mappings.
>>
>>    The address and port mapping high threshold event is generated, when
>>    the number of ports in the configured address pool has reached a
>>    configured threshold.
>>
>>    The per-user address and port mapping high threshold is generated
>>    when a single user uses more address and port mapping than a
>>    configured threshold.
>>
>> +---------------------------------------------------------+--------+
>>    |              Threshold Exceeded Event Name              | Values |
>> +---------------------------------------------------------+--------+
>>    |            Address pool high threshold event            |      1 |
>>    |             Address pool low threshold event            |      2 |
>>    |      Address and port mapping high threshold event      |      3 |
>>    |  Address and port mapping per user high threshold event |      4 |
>>    |       Global Address mapping high threshold event       |      5 |
>> +---------------------------------------------------------+--------+
>>
>>                       Table 4: Threshold event table
>>
>> 5.6.  Templates for NAT Events
>>
>>    The following is the template of events that will have to logged.
>> ^^^^^^^^^^^^^^^^^^^
>>
>> SD: I think this is a nit, but the sentence is garbled. "will be logged"?
>>
>>    The events below are identified at the time of this writing but the
>>    events are expandable.  Depending on the implementation and
>>    ^^^^^^^^^^^^^^^^^^^^^
>> SD: this is a nit, but "set of events is extensible", I think.
>>
>> [Senthil] Agree. (to both comments).
>
> Thanks,
>
>>    configuration various IE's specified can be included or ignored.
>>
>> 5.6.1.  NAT44 create and delete session events
>>
>>    These events will be generated when a NAT44 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.
>>
>>    The destination address and port information is optional as required
>>    by [RFC6888].  However, when the destination information is
>>    suppressed, the session log event contains the same information as
>>    the BIB event.  In such cases, the NAT device SHOULD NOT send both
>>    BIB and session events.
>>
>> +----------------------------------+-------------+-----------+
>>       |            Field Name            | Size (bits) | Mandatory |
>> +----------------------------------+-------------+-----------+
>>       |            timeStamp             |          64 |    Yes    |
>>       |          natInstanceID           |          32 |     No    |
>>       |       vlanID/ingressVRFID        |          32 |     No    |
>>       |        sourceIPv4Address         |          32 |    Yes    |
>>       |     postNATSourceIPv4Address     |          32 |    Yes    |
>>       |        protocolIdentifier        |           8 |    Yes    |
>>       |       sourceTransportPort        |          16 |    Yes    |
>>       |   postNAPTsourceTransportPort    |          16 |    Yes    |
>>       |      destinationIPv4Address      |          32 |     No    |
>>       |  postNATDestinationIPv4Address   |          32 |     No    |
>>       |     destinationTransportPort     |          16 |     No    |
>>       | postNAPTdestinationTransportPort |          16 |     No    |
>>       |       internalAddressRealm       |           8 |     No    |
>>       |       externalAddressRealm       |           8 |     No    |
>>       |             natEvent             |           8 |    Yes    |
>> +----------------------------------+-------------+-----------+
>>
>>                Table 5: NAT44 Session delete/create template
>>
>> 5.6.2.  NAT64 create and delete session events
>>
>>    These events will be generated when a NAT64 session is created or
>>    deleted.  The following is a template of the event.
>>
>> +----------------------------------+-------------+-----------+
>>       |            Field Name            | Size (bits) | Mandatory |
>> +----------------------------------+-------------+-----------+
>>       |            timeStamp             |          64 |    Yes    |
>>       |          natInstanceID           |          32 |     No    |
>>       |       vlanID/ingressVRFID        |          32 |     No    |
>>       |        sourceIPv6Address         |         128 |    Yes    |
>>       |     postNATSourceIPv4Address     |          32 |    Yes    |
>>       |        protocolIdentifier        |           8 |    Yes    |
>>       |       sourceTransportPort        |          16 |    Yes    |
>>       |   postNAPTsourceTransportPort    |          16 |    Yes    |
>>       |      destinationIPv6Address      |         128 |     No    |
>>       |  postNATDestinationIPv4Address   |          32 |     No    |
>>       |     destinationTransportPort     |          16 |     No    |
>>       | postNAPTdestinationTransportPort |          16 |     No    |
>>       |       internalAddressRealm       |           8 |     No    |
>>       |       externalAddressRealm       |           8 |     No    |
>>       |             natEvent             |           8 |    Yes    |
>> +----------------------------------+-------------+-----------+
>>
>>             Table 6: NAT64 session create/delete event template
>>
>> 5.6.3.  NAT44 BIB create and delete events
>>
>>    These events will be generated when a NAT44 Bind entry is created or
>>    deleted.  The following is a template of the event.
>>
>> +-----------------------------+-------------+-----------+
>>          |          Field Name         | Size (bits) | Mandatory |
>> +-----------------------------+-------------+-----------+
>>          |          timeStamp          |          64 |    Yes    |
>>          |        natInstanceID        |          32 |     No    |
>>          |     vlanID/ingressVRFID     |          32 |     No    |
>>          |      sourceIPv4Address      |          32 |    Yes    |
>>          |   postNATSourceIPv4Address  |          32 |    Yes    |
>>          |      protocolIdentifier     |           8 |     No    |
>>          |     sourceTransportPort     |          16 |     No    |
>>          | postNAPTsourceTransportPort |          16 |     No    |
>>          |     internalAddressRealm    |           8 |     No    |
>>          |     externalAddressRealm    |           8 |     No    |
>>          |           natEvent          |           8 |    Yes    |
>> +-----------------------------+-------------+-----------+
>>
>>               Table 7: NAT44 BIB create/delete event template
>>
>> 5.6.4.  NAT64 BIB create and delete events
>>
>>    These events will be generated when a NAT64 Bind entry is created or
>>    deleted.  The following is a template of the event.
>>
>> +-----------------------------+-------------+-----------+
>>          |          Field Name         | Size (bits) | Mandatory |
>> +-----------------------------+-------------+-----------+
>>          |          timeStamp          |          64 |    Yes    |
>>          |        natInstanceID        |          32 |     No    |
>>          |     vlanID/ingressVRFID     |          32 |     No    |
>>          |      sourceIPv6Address      |         128 |    Yes    |
>>          |   postNATSourceIPv4Address  |          32 |    Yes    |
>>          |      protocolIdentifier     |           8 |     No    |
>>          |     sourceTransportPort     |          16 |     No    |
>>          | postNAPTsourceTransportPort |          16 |     No    |
>>          |     internalAddressRealm    |           8 |     No    |
>>          |     externalAddressRealm    |           8 |     No    |
>>          |           natEvent          |           8 |    Yes    |
>> +-----------------------------+-------------+-----------+
>>
>>               Table 8: NAT64 BIB create/delete event template
>>
>> 5.6.5.  Addresses Exhausted event
>>
>>    This event will be generated when a NAT device runs out of global
>>    IPv4 addresses in a given pool of addresses. Typically, this event
>>    would mean that the NAT device wont be able to create any new
>>                                   ^^^^
>> SD: "won't"
>>
>> [Senthil] Ok.
>
> Thanks,
>
>>
>>    translations until some addresses/ports are freed.  This event SHOULD
>>    be rate limited as many packets hitting the device at the same time
>>    will trigger a burst of addresses exhausted events.
>>
>>    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.
>>
>> SD: I lack understanding, but I didn't see anything that looked like 
>> a NAT pool name in the template. Did I miss something?
>>
>> [Senthil] We decided not to use a string like a pool name instead use 
>> a poolID, which is a unique identifier for each pool name. The reason 
>> being that the logs could become fairly large
>> If we have to carry the names and some of the NAT engines implement 
>> this in the hardware that lacks the string processing capability.
>
> OK, that helps. I'm understanding that a different template might have 
> included a pool name, but not a poolID, is that right?
>
> I'm somewhat uneasy about the "either should be logged, but not both" 
> text.
>
> Same question as usual - is this an RFC 2119 SHOULD that helps with 
> interoperation, or is this about an implementation choice?
>
> If it's an RFC 2119 SHOULD, robust collectors will need to do 
> something if a log arrives with both a pool name and a poolID. If it's 
> a MUST, a collector wouldn't accept the log (however the collector 
> would decide to do that).
>
> If it's not an RFC 2119 SHOULD, but just implementation guidance, the 
> explanation you provided would be more helpful (something like "could 
> include a pool name, but some NAT engines are implemented in hardware 
> that lacks string processing capability, and these are permitted to 
> substitute a poolID. There's no reason to provide both a pool name and 
> a poolID").
>
>> +---------------+-------------+-----------+
>>                 |   Field Name  | Size (bits) | Mandatory |
>> +---------------+-------------+-----------+
>>                 |   timeStamp   |          64 | Yes    |
>>                 | natInstanceID |          32 | No    |
>>                 |    natEvent   |           8 | Yes    |
>>                 |   natPoolID   |          32 | Yes    |
>> +---------------+-------------+-----------+
>>
>>                  Table 9: Address Exhausted event template
>>
>> 5.6.6.  Ports Exhausted event
>>
>>    This event will be generated when a NAT device runs out of ports for
>>    a global IPv4 address.  Port exhaustion shall be reported per
>>    protocol (UDP, TCP etc).  This event SHOULD be rate limited as many
>>    packets hitting the device at the same time will trigger a burst of
>>    port exhausted events.
>>
>>    The following is a template of the event.
>>
>> +--------------------------+-------------+-----------+
>>           |        Field Name        | Size (bits) | Mandatory |
>> +--------------------------+-------------+-----------+
>>           |        timeStamp         |          64 | Yes    |
>>           |      natInstanceID       |          32 | No    |
>>           |         natEvent         |           8 | Yes    |
>>           | postNATSourceIPv4Address |          32 | Yes    |
>>           |    protocolIdentifier    |           8 | Yes    |
>> +--------------------------+-------------+-----------+
>>
>>                  Table 10: Ports Exhausted event template
>>
>> 5.6.7.  Quota exceeded events
>>
>>    This event will be generated when a NAT device cannot allocate
>>    resources as a result of an administratively defined policy.  The
>>    quota exceeded event templates are described below
>>                                                      ^
>> SD: missing period
>> [Senthil] Ok.
>
> Thanks,
>
>> 5.6.7.1.  Maximum session entries exceeded
>>
>>    The maximum session entries exceeded is generated when the
>>    administratively configured limit is reached.  The following is the
>>    template of the event.
>>
>> +-----------------+-------------+-----------+
>>                |    Field Name   | Size (bits) | Mandatory |
>> +-----------------+-------------+-----------+
>>                |    timeStamp    |          64 | Yes    |
>>                |  natInstanceID  |          32 | No    |
>>                |     natEvent    |           8 | Yes    |
>>                |  natLimitEvent  |          32 | Yes    |
>>                | configuredLimit |          32 | Yes    |
>> +-----------------+-------------+-----------+
>>
>>              Table 11: Session Entries Exceeded event template
>>
>> 5.6.7.2.  Maximum BIB entries exceeded
>>
>>    The maximum BIB entries exceeded is generated when the
>>    administratively configured limit is reached.  The following is the
>>    template of the event.
>>
>> +-----------------+-------------+-----------+
>>                |    Field Name   | Size (bits) | Mandatory |
>> +-----------------+-------------+-----------+
>>                |    timeStamp    |          64 | Yes    |
>>                |  natInstanceID  |          32 | No    |
>>                |     natEvent    |           8 | Yes    |
>>                |  natLimitEvent  |          32 | Yes    |
>>                | configuredLimit |          32 | Yes    |
>> +-----------------+-------------+-----------+
>>
>>                Table 12: BIB Entries Exceeded event template
>>
>> 5.6.7.3.  Maximum entries per user exceeded
>>
>>    This event is generated when a single user reaches the
>>    administratively configured limit.  The following is the template of
>>    the event.
>>
>> +---------------------+-------------+---------------+
>>            |      Field Name     | Size (bits) | Mandatory   |
>> +---------------------+-------------+---------------+
>>            |      timeStamp      |          64 | Yes      |
>>            |    natInstanceID    |          32 | No      |
>>            |       natEvent      |           8 | Yes      |
>>            |    natLimitEvent    |          32 | Yes      |
>>            |   configuredLimit   |          32 | Yes      |
>>            | vlanID/ingressVRFID |          32 | No      |
>>            |  sourceIPv4 address |          32 | Yes for NAT44 |
>>            |  sourceIPv6 address |         128 | Yes for NAT64 |
>> +---------------------+-------------+---------------+
>>
>>             Table 13: Per-user Entries Exceeded event template
>>
>> 5.6.7.4.  Maximum active host or subscribers exceeded
>>
>>    This event is generated when the number of allowed hosts or
>>    subscribers reaches the administratively configured limit.  The
>>    following is the template of the event.
>>
>> +-----------------+-------------+-----------+
>>                |    Field Name   | Size (bits) | Mandatory |
>> +-----------------+-------------+-----------+
>>                |    timeStamp    |          64 | Yes    |
>>                |  natInstanceID  |          32 | No    |
>>                |     natEvent    |           8 | Yes    |
>>                |  natLimitEvent  |          32 | Yes    |
>>                | configuredLimit |          32 | Yes    |
>> +-----------------+-------------+-----------+
>>
>>         Table 14: Maximum hosts/subscribers Exceeded event template
>>
>> 5.6.7.5.  Maximum fragments pending reassembly exceeded
>>
>>    This event is generated when the number of fragments pending
>>    reassembly reaches the administratively configured limit.  The
>>    following is the template of the event.
>>
>> +----------------------+-------------+---------------+
>>           |      Field Name      | Size (bits) | Mandatory   |
>> +----------------------+-------------+---------------+
>>           |      timeStamp       |          64 | Yes      |
>>           |    natInstanceID     |          32 | No      |
>>           |       natEvent       |           8 | Yes      |
>>           |    natLimitEvent     |          32 | Yes      |
>>           |   configuredLimit    |          32 | Yes      |
>>           | internalAddressRealm |           8 | Yes      |
>>           | vlanID/ingressVRFID  |          32 | No      |
>>           |  sourceIPv4 address  |          32 | Yes for NAT44 |
>>           |  sourceIPv6 address  |         128 | Yes for NAT64 |
>> +----------------------+-------------+---------------+
>>
>>        Table 15: Maximum fragments pending reassembly Exceeded event
>>                                  template
>>
>> 5.6.8.  Threshold reached events
>>
>>    This event will be generated when a NAT device reaches a operator
>>    configured threshold when allocating resources.  The threshold
>>    reached events are described in the section above. The following is
>>    a template of the individual events.
>>
>> 5.6.8.1.  Address pool high or low threshold reached
>>
>>    This event is generated when the high or low threshold is reached for
>>    the address pool.  The template is the same for both high and low
>>    threshold events
>>
>> +-------------------+-------------+-----------+
>>               |     Field Name    | Size (bits) | Mandatory |
>> +-------------------+-------------+-----------+
>>               |     timeStamp     |          64 | Yes    |
>>               |   natInstanceID   |          32 | No    |
>>               |      natEvent     |           8 | Yes    |
>>               | natThresholdEvent |          32 | Yes    |
>>               |     natPoolID     |          32 | Yes    |
>>               |  configuredLimit  |          32 | Yes    |
>> +-------------------+-------------+-----------+
>>
>>      Table 16: Address pool high/low threshold reached event template
>>
>> 5.6.8.2.  Address and port high threshold reached
>>
>>    This event is generated when the high threshold is reached for the
>>    address pool and ports.
>>
>> +-------------------+-------------+-----------+
>>               |     Field Name    | Size (bits) | Mandatory |
>> +-------------------+-------------+-----------+
>>               |     timeStamp     |          64 | Yes    |
>>               |   natInstanceID   |          32 | No    |
>>               |      natEvent     |           8 | Yes    |
>>               | natThresholdEvent |          32 | Yes    |
>>               |  configuredLimit  |          32 | Yes    |
>> +-------------------+-------------+-----------+
>>
>>        Table 17: Address port high threshold reached event template
>>
>> 5.6.8.3.  Per-user Address and port high threshold reached
>>
>>    This event is generated when the high threshold is reached for the
>>    per-user address pool and ports.
>>
>> +---------------------+-------------+---------------+
>>            |      Field Name     | Size (bits) | Mandatory   |
>> +---------------------+-------------+---------------+
>>            |      timeStamp      |          64 | Yes      |
>>            |    natInstanceID    |          32 | No      |
>>            |       natEvent      |           8 | Yes      |
>>            |  natThresholdEvent  |          32 | Yes      |
>>            |   configuredLimit   |          32 | Yes      |
>>            | vlanID/ingressVRFID |          32 | No      |
>>            |  sourceIPv4 address |          32 | Yes for NAT44 |
>>            |  sourceIPv6 address |         128 | Yes for NAT64 |
>> +---------------------+-------------+---------------+
>>
>>    Table 18: Per-user Address port high threshold reached event template
>>
>> 5.6.8.4.  Global Address mapping high threshold reached
>>
>>    This event is generated when the high is reached for the per-user
>>    address pool and ports.  This is generated only by NAT devices that
>>    use a address pooling behavior of paired.
>>
>> +---------------------+-------------+-----------+
>>              |      Field Name     | Size (bits) | Mandatory |
>> +---------------------+-------------+-----------+
>>              |      timeStamp      |          64 | Yes    |
>>              |    natInstanceID    |          32 | No    |
>>              |       natEvent      |           8 | Yes    |
>>              |  natThresholdEvent  |          32 | Yes    |
>>              |   configuredLimit   |          32 | Yes    |
>>              | vlanID/ingressVRFID |          32 | No    |
>> +---------------------+-------------+-----------+
>>
>>        Table 19: Global Address mapping high threshold reached event
>>                                  template
>>
>> 5.6.9.  Address binding create and delete events
>>
>>    These events will be generated when a NAT device binds a local
>>    address with a global address and when the global address is freed.
>>    This binding event happens when the first packet of the first flow
>>    from a host in the private realm.
>>
>> +--------------------------------+-------------+---------------+
>>      |           Field Name           | Size (bits) | Mandatory   |
>> +--------------------------------+-------------+---------------+
>>      |           timeStamp            |          64 |      Yes      |
>>      |         natInstanceID          |          32 |       No      |
>>      |            natEvent            |           8 |      Yes      |
>>      |       sourceIPv4 address       |          32 | Yes for NAT44 |
>>      |       sourceIPv6 address       |         128 | Yes for NAT64 |
>>      | Translated Source IPv4 Address |          32 |      Yes      |
>> +--------------------------------+-------------+---------------+
>>
>>                   Table 20: NAT Address Binding template
>>
>> 5.6.10.  Port block allocation and de-allocation
>>
>>    This event will be generated when a NAT device allocates/de-allocates
>>    ports in a bulk fashion, as opposed to allocating a port on a per
>>    flow basis.
>>
>>    portRangeStart represents the starting value of the range.
>>
>>    portRangeEnd represents the ending value of the range.
>>
>>    NAT devices would do this in order to reduce logs and potentially to
>>    limit the number of connections a subscriber is allowed to use.  In
>>    the following Port Block allocation template, the portRangeStart and
>>    portRangeEnd must be specified.
>>
>>
>> Sivakumar & Penno        Expires August 15, 2014               [Page 17]
>>
>> Internet-Draft          IPFIX IEs for NAT logging          February 2014
>>
>>    It is up to the implementation to choose to consolidate log records
>>    in case two consecutive port ranges for the same user are allocated
>>    or freed.
>>
>> +--------------------------------+-------------+---------------+
>>      |           Field Name           | Size (bits) | Mandatory   |
>> +--------------------------------+-------------+---------------+
>>      |           timeStamp            |          64 |      Yes      |
>>      |         natInstanceID          |          32 |       No      |
>>      |            natEvent            |           8 |      Yes      |
>>      |       sourceIPv4 address       |          32 | Yes for NAT44 |
>>      |       sourceIPv6 address       |         128 | Yes for NAT64 |
>>      | Translated Source IPv4 Address |          32 |      Yes      |
>>      |         portRangeStart         |          16 |      Yes      |
>>      |          portRangeEnd          |          16 |       No      |
>> +--------------------------------+-------------+---------------+
>>
>>             Table 21: NAT Port Block Allocation event template
>>
>> 6.  Encoding
>>
>> 6.1.  IPFIX
>>
>>    This document uses IPFIX as the encoding mechanism to describe the
>>    logging of NAT events.  However, the information that should be
>>    logged SHOULD be the same irrespective of what kind of encoding
>>    scheme is used.  IPFIX is chosen because is it an IETF standard that
>>    meets all the needs for a reliable logging mechanism.  IPFIX provides
>>    the flexibility to the logging device to define the data sets that it
>>    is logging.  The IEs specified for logging MUST be the same
>>    irrespective of the encoding mechanism used.
>>
>> 7.  Acknowledgements
>>
>>    Thanks to Dan Wing, Selvi Shanmugam, Mohamed Boucadir, Jacni Qin
>>    Ramji Vaithianathan, Simon Perreault, Jean-Francois Tremblay, Paul
>>    Aitken and Julia Renouard for their review and comments.
>>
>> 8.  IANA Considerations
>>
>>    The following information elements are requested from IANA IPFIX
>>    registry.
>>
>>    natInstanceId
>>
>>    externalAddressRealm
>>
>>    natLimitEvent
>>
>> 9.  Management Considerations
>>
>>    This section considers requirements for management of the log system
>>    to support logging of the events described above.  It first covers
>>    requirements applicable to log management in general.  Any additional
>>    standardization required to fullfil these requirements is out of
>>    scope of the present document.  Some management considerations is
>>    covered in [I-D.behave-syslog-nat-logging].  This document covers the
>>    additional considerations.
>>
>> 9.1.  Ability to collect events from multiple NAT devices
>>
>>    An IPFIX collector should be able to collect events from multiple NAT
>>    devices and be able to decipher events based on the sourceID in the
>>    IPFIX header.
>>
>> 9.2.  Ability to suppress events
>>
>>    The exhaustion events can be overwhelming during traffic bursts and
>>    hence should be handled by the NAT devices to rate limit them before
>>    sending them to the collectors.  For eg. when the port exhaustion
>>    happens during bursty conditions, instead of sending a port
>>    exhaustion event for every packet, the exhaustion events should be
>>    rate limited by the NAT device.
>>
>> 10.  Security Considerations
>>
>>    None.
>>
>> 11.  References
>>
>> 11.1.  Normative References
>>
>>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>>
>>    [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
>>               Translator (NAT) Terminology and Considerations", RFC
>>               2663, August 1999.
>>
>>    [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
>>               (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
>>               RFC 4787, January 2007.
>>
>>    [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
>>               Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
>>               RFC 5382, October 2008.
>>
>>    [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
>>               NAT64: Network Address and Protocol Translation from IPv6
>>               Clients to IPv4 Servers", RFC 6146, April 2011.
>>
>>    [RFC6302]  Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
>>               "Logging Recommendations for Internet-Facing Servers", BCP
>>               162, RFC 6302, June 2011.
>>
>>    [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
>>               and H. Ashida, "Common Requirements for Carrier-Grade NATs
>>               (CGNs)", BCP 127, RFC 6888, April 2013.
>>
>> 11.2.  Informative References
>>
>>    [I-D.ietf-behave-syslog-nat-logging]
>>               Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog
>>               Format for NAT Logging", draft-ietf-behave-syslog-nat-
>>               logging-06 (work in progress), January 2014.
>>
>>    [IPFIX-IANA]
>>               IANA, "IPFIX Information Elements registry",
>> <http://www.iana.org/assignments/ipfix>.
>>
>>    [RFC5101bis]
>>               Claise, B. and B. Trammel, "Specification of the IP Flow
>>               Information eXport (IPFIX) Protocol for the Exchange of
>>               Flow Information", July 2013.
>>
>>    [RFC5102bis]
>>               Claise, B. and B. Trammel, "Information Model for IP Flow
>>               Information eXport (IPFIX)", February 2013.
>>
>>    [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
>>               "Architecture for IP Flow Information Export", RFC 5470,
>>               March 2009.
>>
>> Authors' Addresses
>>
>>    Senthil Sivakumar
>>    Cisco Systems
>>    7100-8 Kit Creek Road
>>    Research Triangle Park, North Carolina  27709
>>    USA
>>
>>    Phone: [phone]
>>
>>    Renaldo Penno
>>    Cisco Systems
>>    170 W Tasman Drive
>>    San Jose, California  95035
>>    USA
>>
>>    Email: [e-mail]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Sivakumar & Penno        Expires August 15, 2014               [Page 21]
>