   to the management of NAT resources. The creation and del= etion 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 flowi= ng
   through the NAT device or through an external entity installin= g
   policies on the NAT router or as a result of an asynchronous e= vent
   like a timer. The list of events are provided in Section= 4.1. Each
   of these events SHOULD be logged, unless they are administrati= vely
   prohibited. A NAT device MAY log these events to multipl= e collectors
   if redundancy is required. The network administrator wil= l specify
   the collectors to which the log records are to be sent.

   A collector may receive NAT events from multiple CGN devices a= nd
   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. T= he 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 i= s a collector that some application writer will

develop.

   is part of the IPFIX template and data exchange.

   Prior to logging any events, the NAT device MUST send the temp= late of
   the record to the collector to advertise the format of the dat= a
   record that it is using to send the events. The template= s can be
   exchanged as frequently as required given the reliability of t= he
   connection. There SHOULD be a configurable timer for con= trolling the
   template refresh. NAT device SHOULD combine as many even= ts 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 dis= cussed
   in [RFC6302] and [RFC6888]. Logging of destination infor= mation
   increases the size of each record and increases the need for s= torage
   considerably. It increases the number of log events gene= rated
   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 an= d hence
   should be done with caution. However, this draft provide= s the
   necessary fields to log the destination information in cases w= here
   they are required to be logged.

5.2. Information Elements

   The templates could contain a subset of the Information Elemen= ts(IEs)
   shown in Table 1 depending upon the event being logged. = For example
   a NAT44 session creation template record will contain,
            &nb= sp;            =             &nb= sp;      ^^^^
SD: Is this the only possible NAT44 template? If so, fine, but if not, perh= aps "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.

   {sourceIPv4Adress, postNATSourceIPv4Address, destinationIpv4Ad= dress,
   postNATDestinationIPv4Address, sourceTransportPort,
   postNAPTSourceTransportPort, destinationTransportPort,
   postNAPTDestTransportPort, internalAddressRealm, natEvent, tim= eStamp}

   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, 14= 800,
   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 w= ould
   need to export the events. The formats of the IE's and t= he 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-element= s 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 somet= hing that already existed in the IPFIX registry rather than asking for a ne= w 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 d= escription that is called observationTimeMilliSeconds". The other fiel= d 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=92t stick to the= same terminology, so I don=92t 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 s= hould stick to the existing IPFIX IANA terminology or the behave documents terminology.

[Senthil] Agree. (to both comments).

[Senthil] Ok.

   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 eith= er 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 th= is in the hardware that lacks the string processing capability.

[Senthil] Ok.

5.6.7.1. Maximum session entries exceeded

   The maximum session entries exceeded is generated when the
   administratively configured limit is reached. The follow= ing is the
   template of the event.

            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    Field Name   | Size (bits) | Mandat= ory |
            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    timeStamp    |  &nbs= p;       64 |    Yes &nbs= p; |
            &nb= sp; | natInstanceID |      =     32 |     No    |
            &nb= sp; |     natEvent    |  = ;         8 |    Yes=     |
            &nb= sp; | natLimitEvent |      =     32 |    Yes    |
            &nb= sp; | configuredLimit |       &nbs= p; 32 |    Yes    |
            &nb= sp; +-----------------+-------------+-----------+

             Ta= ble 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 follow= ing is the
   template of the event.

            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    Field Name   | Size (bits) | Mandat= ory |
            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    timeStamp    |  &nbs= p;       64 |    Yes &nbs= p; |
            &nb= sp; | natInstanceID |      =     32 |     No    |
            &nb= sp; |     natEvent    |  = ;         8 |    Yes=     |
            &nb= sp; | natLimitEvent |      =     32 |    Yes    |
            &nb= sp; | configuredLimit |       &nbs= p; 32 |    Yes    |
            &nb= sp; +-----------------+-------------+-----------+

            &nb= sp; 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.

           +---------= ------------+-------------+---------------+
           |  &= nbsp;   Field Name     | Size (bits) | &= nbsp; Mandatory   |
           +---------= ------------+-------------+---------------+
           |  &= nbsp;   timeStamp      |  &nbs= p;       64 |      Y= es      |
           |  &= nbsp; natInstanceID    |      =     32 |       No  &= nbsp;   |
           |  &= nbsp;    natEvent      |  = ;         8 |   &nbs= p; Yes      |
           |  &= nbsp; natLimitEvent    |      =     32 |      Yes   =    |
           |   = configuredLimit   |       &nbs= p; 32 |      Yes    &nbs= p; |
           | vlanID/ingre= ssVRFID |          32 | &= nbsp;     No      |
           | source= IPv4 address |          32 | Y= es for NAT44 |
           | source= IPv6 address |         128 | Yes fo= r 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.&nbs= p; The
   following is the template of the event.

            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    Field Name   | Size (bits) | Mandat= ory |
            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    timeStamp    |  &nbs= p;       64 |    Yes &nbs= p; |
            &nb= sp; | natInstanceID |      =     32 |     No    |
            &nb= sp; |     natEvent    |  = ;         8 |    Yes=     |
            &nb= sp; | natLimitEvent |      =     32 |    Yes    |
            &nb= sp; | configuredLimit |       &nbs= p; 32 |    Yes    |
            &nb= sp; +-----------------+-------------+-----------+

        Table 14: Maximum hosts/subscrib= ers 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.

          +---------------= -------+-------------+---------------+
          |   &= nbsp; Field Name      | Size (bits) | &= nbsp; Mandatory   |
          +---------------= -------+-------------+---------------+
          |   &= nbsp; timeStamp       |  &nbs= p;       64 |      Y= es      |
          |    = natInstanceID     |      =     32 |       No  &= nbsp;   |
          |   &= nbsp;   natEvent       |  = ;         8 |   &nbs= p; Yes      |
          |    = natLimitEvent     |      =     32 |      Yes   =    |
          |   config= uredLimit    |       &nbs= p; 32 |      Yes    &nbs= p; |
          | internalAddressRea= lm |           8 | &= nbsp;    Yes      |
          | vlanID/ingressVRFI= D |          32 | &= nbsp;     No      |
          | sourceIPv4 a= ddress |          32 | Y= es for NAT44 |
          | sourceIPv6 a= ddress |         128 | Yes fo= r NAT64 |
          +---------------= -------+-------------+---------------+

       Table 15: Maximum fragments pending re= assembly Exceeded event
            &nb= sp;            =         template

5.6.8. Threshold reached events

   This event will be generated when a NAT device reaches a opera= tor
   configured threshold when allocating resources. The thre= shold
   reached events are described in the section above. The f= ollowing 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 reac= hed for
   the address pool. The template is the same for both high= and low
   threshold events

            &nb= sp; +-------------------+-------------+-----------+
            &nb= sp; |     Field Name    | Size (bits) | = Mandatory |
            &nb= sp; +-------------------+-------------+-----------+
            &nb= sp; |     timeStamp     | &nbs= p;        64 |    Yes&nbs= p;   |
            &nb= sp; |   natInstanceID   |     =      32 |     No    = |
            &nb= sp; |      natEvent     | = ;          8 |  &nbs= p; Yes    |
            &nb= sp; | natThresholdEvent |        &n= bsp; 32 |    Yes    |
            &nb= sp; |     natPoolID     | &nbs= p;        32 |    Yes&nbs= p;   |
            &nb= sp; | configuredLimit |      &nbs= p;   32 |    Yes    |
            &nb= sp; +-------------------+-------------+-----------+

     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.

            &nb= sp; +-------------------+-------------+-----------+
            &nb= sp; |     Field Name    | Size (bits) | = Mandatory |
            &nb= sp; +-------------------+-------------+-----------+
            &nb= sp; |     timeStamp     | &nbs= p;        64 |    Yes&nbs= p;   |
            &nb= sp; |   natInstanceID   |     =      32 |     No    = |
            &nb= sp; |      natEvent     | = ;          8 |  &nbs= p; Yes    |
            &nb= sp; | natThresholdEvent |        &n= bsp; 32 |    Yes    |
            &nb= sp; | configuredLimit |      &nbs= p;   32 |    Yes    |
            &nb= sp; +-------------------+-------------+-----------+

       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.

           +---------= ------------+-------------+---------------+
           |  &= nbsp;   Field Name     | Size (bits) | &= nbsp; Mandatory   |
           +---------= ------------+-------------+---------------+
           |  &= nbsp;   timeStamp      |  &nbs= p;       64 |      Y= es      |
           |  &= nbsp; natInstanceID    |      =     32 |       No  &= nbsp;   |
           |  &= nbsp;    natEvent      |  = ;         8 |   &nbs= p; Yes      |
           | natThr= esholdEvent |          3= 2 |      Yes      |
           |   = configuredLimit   |       &nbs= p; 32 |      Yes    &nbs= p; |
           | vlanID/ingre= ssVRFID |          32 | &= nbsp;     No      |
           | source= IPv4 address |          32 | Y= es for NAT44 |
           | source= IPv6 address |         128 | Yes fo= r NAT64 |
           +---------= ------------+-------------+---------------+

   Table 18: Per-user Address port high threshold reached event t= emplate

5.6.8.4. Global Address mapping high threshold reached

   This event is generated when the high is reached for the per-u= ser
   address pool and ports. This is generated only by NAT de= vices that
   use a address pooling behavior of paired.

             &#= 43;---------------------+-------------+-----------+
             |&= nbsp;     Field Name     | Size (bi= ts) | Mandatory |
             &#= 43;---------------------+-------------+-----------+
             |&= nbsp;     timeStamp      |&nbs= p;         64 |    Y= es    |
             |&= nbsp;   natInstanceID    |    =       32 |     No  &= nbsp; |
             |&= nbsp;      natEvent      = |           8 | &nbs= p; Yes    |
             |&= nbsp; natThresholdEvent |       &n= bsp; 32 |    Yes    |
             |&= nbsp; configuredLimit   |     &nbs= p;    32 |    Yes    |
             | = vlanID/ingressVRFID |         = 32 |     No    |
             &#= 43;---------------------+-------------+-----------+

       Table 19: Global Address mapping high = threshold reached event
            &nb= sp;            =         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 f= reed.
   This binding event happens when the first packet of the first = flow
   from a host in the private realm.

     +--------------------------------+--------= -----+---------------+
     |        &= nbsp; Field Name         = ; | Size (bits) |   Mandatory   |
     +--------------------------------+--------= -----+---------------+
     |        &= nbsp; timeStamp         =    |          64 |&n= bsp;     Yes      |
     |         = natInstanceID          | =          32 |   &nbs= p;   No      |
     |        &= nbsp;   natEvent        &= nbsp;   |         &n= bsp; 8 |      Yes      |<= br>      |       sourceIPv4 a= ddress       |     &= nbsp;    32 | Yes for NAT44 |
     |       sourceIPv6 a= ddress       |     &= nbsp;   128 | Yes for NAT64 |
     | Translated Source IPv4 Address |  &nbs= p;       32 |      Y= es      |
     +--------------------------------+--------= -----+---------------+

            &nb= sp;     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-al= locates
   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 potentia= lly to
   limit the number of connections a subscriber is allowed to use= . In
   the following Port Block allocation template, the portRangeSta= rt and
   portRangeEnd must be specified.

Sivakumar & Penno        Expires Aug= ust 15, 2014          &nb= sp;    [Page 17]

Internet-Draft          IPFIX = IEs for NAT logging          F= ebruary 2014

   It is up to the implementation to choose to consolidate log re= cords
   in case two consecutive port ranges for the same user are allo= cated
   or freed.

     +--------------------------------+--------= -----+---------------+
     |        &= nbsp; Field Name         = ; | Size (bits) |   Mandatory   |
     +--------------------------------+--------= -----+---------------+
     |        &= nbsp; timeStamp         =    |          64 |&n= bsp;     Yes      |
     |         = natInstanceID          | =          32 |   &nbs= p;   No      |
     |        &= nbsp;   natEvent        &= nbsp;   |         &n= bsp; 8 |      Yes      |<= br>      |       sourceIPv4 a= ddress       |     &= nbsp;    32 | Yes for NAT44 |
     |       sourceIPv6 a= ddress       |     &= nbsp;   128 | Yes for NAT64 |
     | Translated Source IPv4 Address |  &nbs= p;       32 |      Y= es      |
     |         = portRangeStart         |  = ;        16 |    &nb= sp; Yes      |
     |        &= nbsp; portRangeEnd          |&= nbsp;         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 sho= uld be
   logged SHOULD be the same irrespective of what kind of encodin= g
   scheme is used. IPFIX is chosen because is it an IETF st= andard that
   meets all the needs for a reliable logging mechanism. IP= FIX provides
   the flexibility to the logging device to define the data sets = that it
   is logging. The IEs specified for logging MUST be the sa= me
   irrespective of the encoding mechanism used.

7. Acknowledgements

   Thanks to Dan Wing, Selvi Shanmugam, Mohamed Boucadir, Jacni Q= in
   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 IPF= IX
   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 fir= st covers
   requirements applicable to log management in general. An= y additional
   standardization required to fullfil these requirements is out = of
   scope of the present document. Some management considera= tions is
   covered in [I-D.behave-syslog-nat-logging]. This documen= t covers the
   additional considerations.

9.1. Ability to collect events from multiple NAT devices

   An IPFIX collector should be able to collect events from multi= ple NAT
   devices and be able to decipher events based on the sourceID i= n the
   IPFIX header.

9.2. Ability to suppress events

   The exhaustion events can be overwhelming during traffic burst= s and
   hence should be handled by the NAT devices to rate limit them = before
   sending them to the collectors. For eg. when the port ex= haustion
   happens during bursty conditions, instead of sending a port    exhaustion event for every packet, the exhaustion events shoul= d 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 t= o Indicate
            &nb= sp; Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2663] Srisuresh, P. and M. Holdrege, "IP Networ= k Address
            &nb= sp; Translator (NAT) Terminology and Considerations", RFC
            &nb= sp; 2663, August 1999.

   [RFC4787] Audet, F. and C. Jennings, "Network Addre= ss Translation
            &nb= sp; (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
            &nb= sp; RFC 4787, January 2007.

   [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S.,= and P.
            &nb= sp; Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,             &nb= sp; RFC 5382, October 2008.

   [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum,= "Stateful
            &nb= sp; NAT64: Network Address and Protocol Translation from IPv6
            &nb= sp; Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. She= ppard,
            &nb= sp; "Logging Recommendations for Internet-Facing Servers", BCP             &nb= sp; 162, RFC 6302, June 2011.

   [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nak= agawa, A.,
            &nb= sp; and H. Ashida, "Common Requirements for Carrier-Grade NATs
            &nb= sp; (CGNs)", BCP 127, RFC 6888, April 2013.

11.2. Informative References

   [I-D.ietf-behave-syslog-nat-logging]
            &nb= sp; Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog
            &nb= sp; Format for NAT Logging", draft-ietf-behave-syslog-nat-
            &nb= sp; logging-06 (work in progress), January 2014.

   [IPFIX-IANA]
            &nb= sp; IANA, "IPFIX Information Elements registry",
            &nb= sp; <http://www.iana.org/assignments/ipfix>.

   [RFC5101bis]
            &nb= sp; Claise, B. and B. Trammel, "Specification of the IP Flow
            &nb= sp; Information eXport (IPFIX) Protocol for the Exchange of
            &nb= sp; Flow Information", July 2013.

   [RFC5102bis]
            &nb= sp; Claise, B. and B. Trammel, "Information Model for IP Flow
            &nb= sp; Information eXport (IPFIX)", February 2013.

   [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J= . Quittek,
            &nb= sp; "Architecture for IP Flow Information Export", RFC 5470,
            &nb= sp; March 2009.

Authors' Addresses

   Senthil Sivakumar
   Cisco Systems
   7100-8 Kit Creek Road
   Research Triangle Park, North Carolina 27709
   USA

   Phone: +1 919 392 5158

   Renaldo Penno
   Cisco Systems
   170 W Tasman Drive
   San Jose, California 95035
   USA

   Email: repenno@cisco.com

Sivakumar & Penno        Expires Aug= ust 15, 2014          &nb= sp;    [Page 21]

--_000_CF89605B1009FBssenthilciscocom_-- From nobody Wed May 7 08:46:16 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A431A03C7; Wed, 7 May 2014 08:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTIISDTrMPCj; Wed, 7 May 2014 08:46:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 574341A0388; Wed, 7 May 2014 08:46:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: philip_matthews@magma.ca,iljitsch@muada.com,marcelo@it.uc3m.es X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507154612.27685.72540.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 08:46:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/8MUWo_BPHFSyxh5qLW5tGuUlKVw Cc: behave@ietf.org, dthaler@microsoft.com, mls.ietf@gmail.com, spencerdawkins.ietf@gmail.com, dwing@cisco.com, ipr-announce@ietf.org Subject: [BEHAVE] IPR Disclosure: Hitachi, Ltd.'s Statement about IPR related to RFC 6146 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:46:13 -0000 Dear Philip Matthews, Iljitsch van Beijnum, Marcelo Bagnulo: An IPR disclosure that pertains to your RFC entitled "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers" (RFC6146) was submitted to the IETF Secretariat on 2014-05-06 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2355/). The title of the IPR disclosure is "Hitachi, Ltd.'s Statement about IPR related to RFC 6146.""); The IETF Secretariat From nobody Wed May 7 08:47:00 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7463A1A07A0; Wed, 7 May 2014 08:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJWgWgMwzcSn; Wed, 7 May 2014 08:46:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 627E61A0397; Wed, 7 May 2014 08:46:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: philip_matthews@magma.ca, ajs@shinkuro.com, iljitsch@muada.com, marcelo@it.uc3m.es X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507154657.7041.30514.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 08:46:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/Pm3CFr-_5o04oQ4wRg2DxsyCqEc Cc: behave@ietf.org, dthaler@microsoft.com, mls.ietf@gmail.com, spencerdawkins.ietf@gmail.com, dwing@cisco.com, ipr-announce@ietf.org Subject: [BEHAVE] IPR Disclosure: Hitachi, Ltd.'s Statement about IPR related to RFC 6147 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:46:58 -0000 Dear Philip Matthews, Andrew Sullivan, Iljitsch van Beijnum, Marcelo Bagnulo: An IPR disclosure that pertains to your RFC entitled "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers" (RFC6147) was submitted to the IETF Secretariat on 2014-05-06 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2356/). The title of the IPR disclosure is "Hitachi, Ltd.'s Statement about IPR related to RFC 6147.""); The IETF Secretariat From nobody Sat May 24 19:20:31 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD3F1A0088 for ; Fri, 23 May 2014 14:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.682 X-Spam-Level: * X-Spam-Status: No, score=1.682 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNXvzMhRh-jW for ; Fri, 23 May 2014 14:06:03 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6D61A0086 for ; Fri, 23 May 2014 14:06:02 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id j17so6201969oag.41 for ; Fri, 23 May 2014 14:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=bTEw0YY5Gus7PTk9q9edjp3WZEFb3wO0D+NzGfFLtSM=; b=LRS9FXsv6KwZhpMb2Yojg0v/WaSLFOKACuTcddKtr1GGokjxFjIF8PDYIco/utDSol v64E6ELa9/rhTrldN+dcMpIlee45DYxJmMMMs+ZqLmwS4QzNu7pWme9XeRgrt0zJvWbD kYW4j1Z19rO851rdTGlwEPtjz96UwlK/lw5cMcSzy85VGz9izS9dKvjVg07VntQxetSM prfFNTV3KybNdDV29a3g7OlL0gGWduCwedZg2f0AKGYef5iFF2RcWihPDY3UuQ1uw7J0 DP6mxixA/vB2dUsBziixIptckiDUcZbykdfmQt56xwVVXBgp9uUeVeJcB+YyZwwtalBG dsew== X-Received: by 10.182.43.132 with SMTP id w4mr7921808obl.41.1400879160629; Fri, 23 May 2014 14:06:00 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id gp4sm7427596obb.17.2014.05.23.14.05.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 14:05:59 -0700 (PDT) Message-ID: <537FB834.3010705@gmail.com> Date: Fri, 23 May 2014 16:05:56 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , "draft-ietf-behave-ipfix-nat-logging@tools.ietf.org" References: <5362ADCB.4050802@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030908080302000709080908" Archived-At: http://mailarchive.ietf.org/arch/msg/behave/ocDkbdUjCjUZstUgCUv2o2hnh0Q X-Mailman-Approved-At: Sat, 24 May 2014 19:20:28 -0700 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] AD Evaluation of draft-ietf-behave-ipfix-nat-logging-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 21:06:10 -0000 This is a multi-part message in MIME format. --------------030908080302000709080908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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 > > Date: Thursday, May 1, 2014 4:25 PM > To: "draft-ietf-behave-ipfix-nat-logging@tools.ietf.org > " >

> > Cc: "behave@ietf.org " > > Subject: AD Evaluation of draft-ietf-behave-ipfix-nat-logging-03 > Resent-From:

> > Resent-To: >, Senthil > Sivakumar > > 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", > . > > [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: +1 919 392 5158 > > Renaldo Penno > Cisco Systems > 170 W Tasman Drive > San Jose, California 95035 > USA > > Email: repenno@cisco.com > > > > > > > > > > > > > > > > > > > > > > > Sivakumar & Penno Expires August 15, 2014 [Page 21] --------------030908080302000709080908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

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 <spencerdawkins.ietf@gmail.com>
Date: Thursday, May 1, 2014 4:25 PM
To: "draft-ietf-behave-ipfix-nat-logging@tools.ietf.org" <draft-ietf-behave-ipfix-nat-logging@tools.ietf.org>
Cc: "behave@ietf.org" <behave@ietf.org>
Subject: AD Evaluation of draft-ietf-behave-ipfix-nat-logging-03
Resent-From: <draft-alias-bounces@tools.ietf.org>
Resent-To: <repenno@cisco.com>, Senthil Sivakumar <ssenthil@cisco.com>
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: +1 919 392 5158

�� Renaldo Penno
�� Cisco Systems
�� 170 W Tasman Drive
�� San Jose, California� 95035
�� USA

�� Email: repenno@cisco.com

Sivakumar & Penno�� Expires August 15, 2014�� [Page 21]

--------------030908080302000709080908-- From nobody Wed May 28 08:13:54 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786CE1A01F6 for ; Tue, 27 May 2014 11:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.47 X-Spam-Level: X-Spam-Status: No, score=-11.47 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIjlYB556vws for ; Tue, 27 May 2014 11:30:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32DB1A0650 for ; Tue, 27 May 2014 11:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=192283; q=dns/txt; s=iport; t=1401215403; x=1402425003; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jUmsQD4s+yk9IgI1TGqVirac2ztDied6up3uPH+7nJY=; b=klWixpOeJ5KqG6gQD5D68gGaObwKCkdZXQyQCTpNq9ouErhRHhB/cgG2 8utvU0p1qpO/EcUg6lDGR6MJzcJyqR+PCS94VZncs4YqwaiyYKvFTa1F9 C+EkL0zRz2qcHwF4KCGLqwgV3y9MEQ+pkfJAMuA6IdcaIgHXN/jCc+lQD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgALADbZhFOtJA2M/2dsb2JhbABPBwOCQkVSWLY8DIFaiXoBgQ4WdIIlAQEBBBoBTAcEBw4CAgEIEQECAQIhAQYHGwYRFAMGCAIEAQ0FCYglAxENz1YNhU8XBIwoEIEyAgEFBAEGAQMEHRsBEAcRhC8EjDuJN4ILgXaNNYVygzhsgQEBCBci X-IronPort-AV: E=Sophos;i="4.98,921,1392163200"; d="scan'208,217";a="328294385" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 27 May 2014 18:30:00 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4RIU0B4023788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 18:30:00 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.188]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 27 May 2014 13:29:59 -0500 From: "Senthil Sivakumar (ssenthil)" To: Spencer Dawkins , "draft-ietf-behave-ipfix-nat-logging@tools.ietf.org" Thread-Topic: AD Evaluation of draft-ietf-behave-ipfix-nat-logging-03 Thread-Index: AQHPZXuW1xHWpTEStEWEs33L9nVI5ZstvOcAgCFhhwCABdqugA== Date: Tue, 27 May 2014 18:29:57 +0000 Message-ID: References: <5362ADCB.4050802@gmail.com> <537FB834.3010705@gmail.com> In-Reply-To: <537FB834.3010705@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [64.102.83.140] Content-Type: multipart/alternative; boundary="_000_CFAA34BB106C60ssenthilciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/behave/vJ3RggyCG4mADcUov1PCgM0JEwk X-Mailman-Approved-At: Wed, 28 May 2014 08:13:53 -0700 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] AD Evaluation of draft-ietf-behave-ipfix-nat-logging-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:30:17 -0000 --_000_CFAA34BB106C60ssenthilciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Spencer, Thanks for your comments again, please see inline [Senthil2]. From: Spencer Dawkins > Date: Friday, May 23, 2014 5:05 PM To: Senthil Sivakumar >, "dra= ft-ietf-behave-ipfix-nat-logging@tools.ietf.org" > Cc: "behave@ietf.org" > Subject: Re: AD Evaluation of draft-ietf-behave-ipfix-nat-logging-03 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 versio= n fixing all the issues raised and agreed upon. I will wait for your respon= se. Hi, Senthil, Thanks for being responsive! Just as a high-order bit, many of the questions I asked are whether the dra= ft uses "required" to mean "this is the way it works" - there's a differenc= e between "the sender transmits a log" and "the sender is required to trans= mit 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 exam= ples, 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 w= ord or not. This is a continuing source of controversy in the IETF, especia= lly 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 try= ing to get at. [Senthil2] Ok, thanks. Thanks Senthil From: Spencer Dawkins > Date: Thursday, May 1, 2014 4:25 PM To: "draft-ietf-behave-ipfix-nat-logging@tools.ietf.org" > Cc: "behave@ietf.org" > Subject: AD Evaluation of draft-ietf-behave-ipfix-nat-logging-03 Resent-From: > Resent-To: >, Senthil Sivakumar= > 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 lik= e to see changed before proceeding, but most are editorial. Please take a l= ook, 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 "Operato= rs 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 happen= s 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=85= ", each NAT device logs information in its own proprietary format. I'm just trying to make sure the reader understands what you mean by "behav= e differently" - NAT devices also behave differently when NATting. I had t= o 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 tha= t a NAT device should adhere to. I know this seems tedious, but I'm not able to map what you provided as exp= lanation 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 informati= on. 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 p= roviding requirements anyway), but in the body of the document, it needs to= be clear. [Senthil2] : How about I revise the text as: Network operators expect NAT devices to log events like creation and del= etion of translations and information about the resources it is managing. The logs are essential 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 log the information using propri= etary formats and hence it is difficult to expect a consistent behavior. The lack of = a consistent way to log the data makes it difficult to write the collector= applications that would receive this data and process it to present useful information. This document describes the formats for logging of NAT eve= nts. 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 the= re be a reference to where the requirements are stated? [Senthil] This is the document that is specifying those requirements. Do yo= u 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 t= he use of lower-case terms from RFC 2119 (see my explanation above). This could be "are REQUIRED" (the RFC 2119 requirements language you said y= ou're using), or "are required" (if you change your paragraph about require= ments language to say that case doesn't matter). But "REQUIRED" is "MUST", so changing to "SHOULD" would be a change in your= intended meaning. [Senthil2] I will change this to "are REQUIRED". 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 wi= th the MIB revision? [Senthil2] Not directly, but there is some overlap of information that can = be obtained by using a MIB and the logging mechanisms. 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 "log= ging 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 outsi= de the scope of the document ... [Senthil] Are you objecting to the second part of the last sentence "the ch= oice of actual transport=85", I think the requirement is that the LOG event= s 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 t= ransport 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 u= sually expects from transport protocols, so please be patient. First, I'm confused by the SHOULD with no qualification. When is it OK to l= ose LOG events? [Senthil] Ideally you should never lose the logs, but if the box crashes or= an irrecoverable error happens. Second, you're not giving guidance on selecting a transport protocol, but y= ou are giving guidance about expecting a reliable data channel, whether MUS= T be reliable or SHOULD be reliable. Are there other transport characterist= ics that you expect? For instance, is in-order delivery assumed? Is duplica= te detection by IPFIX assumed (if a log arrives twice, does IPFIX notice)? [Senthil2] There is no need for in-order delivery, the collector should be = able to detect two identical events at the exact same time stamp as duplica= tes. The only transport characteristic required is the reliability. Third, are IPFIX implementations so transport protocol-agnostic that if my = NAT device decides to to send logs using SCTP with partial reliability, I s= hould expect that to work with any collector that implements this specifica= tion? [Senthil2] One of the reasons for not giving the guidance is that IPFIX was= initially SCTP only but in the latest RFC 7011, IPFIX can be transported u= sing TCP/UDP/SCTP and others. As long as both the devices are using IPFIX, and the receiving collector is able to parse and understand SCTP, it should= work. There is a little bit of configuration required, I would think, to t= ell the NAT device on what protocol and port to use, to specify where the c= ollector is listening. 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 manda= tory to implement transport protocol, that wouldn't guarantee interoperatio= n between two standard-conforming devices. [Senthil2] Ok, I don=92t know if in this case, I could pick a transport pro= tocol to use with IPFIX, since IPFIX allows that flexibility and NAT logs a= re transported over IPFIX, people would expect that we support all the tran= sport protocols that IPFIX supports. Let me know if you have better suggest= ions on what the guidance should be. 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 th= e 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 r= elates 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 c= ollector that some application writer will develop. Don't you think you can levy requirements about that on the collector? I do= n't understand. [Senthil2] This document was written for how the NAT devices should send th= eir logs and their formats. I am not sure if I am opening a can of worms, b= y Starting to specify what the collector should do as part of this document. But beyond that, what I THINK the text is saying, is that multiple CGN devi= ces can ("may") send to a single collector, [Senthil2] Yes. that none of the CDN devices have to have a unique source ID to identify th= emselves ("should", but not "must"), ^^^^^ [Senthil2] No, that is not what the text is saying . In fact it says the op= posite, "Each CGN device should have a unique source ID to identify themselves." and that the collector is still expected to be able to distinguish among lo= gs coming from multiple CGNs ("should"). [Senthil2] Yes, the collector should be able to distinguish the records com= ing in from distinct sources. This is a generic IPFIX requirement, That a collector is able to handle multiple sources. Maybe I should remove = this text on the collector as it seems to cause more confusion? Am I misreading this? If not, do you think that works? [Senthil2] Please see above, let me know if I misunderstood what you were a= sking. 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, perh= aps "could contain", or "typically contains"? [Senthil] Yes, this is all the information that a NAT44 need to export as i= t 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. [Senthil2] I think this is the base information required, but difficult to = predict what will be added in the future, so I am going to leave it as is, = unless you have objection. {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 I= PFIX ID number, but others do not ("timeStamp" here doesn't match "observat= ionTimeMilliseconds", but both are IPFIX ID 323, aren't they?) Is there a r= eason 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 term= inology that we use in the NAT drafts/rfc's. So I am open to suggestions he= re. I can clarify in the description that is called observationTimeMilliSec= onds". The other field is internalAddressRealm and externalAddresRealm, thi= s is the terminology that we used in NAT MIB, syslog and other documents. H= owever, when we defined the IPFIX IE, we didn=92t stick to the same termino= logy, so I don=92t know if I can go and ask the IPFIX IANA to change the na= me. Again I am open to suggestions, the dillema is whether I should stick t= o 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 I= PFIX review team. Could you just add a note pointing this question out, and= asking if they have any suggestions? [Senthil2] I will send out an email to the IPFIX mailing list and to the pe= ople who reviewed it from the IPFIX WG. +----------------------------------+--------+-------+---------------+ | 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 poo= lID, 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 incl= uded a pool name, but not a poolID, is that right? I'm somewhat uneasy about the "either should be logged, but not both" text. [Senthil2] That text is not relevant anymore and should be removed, there w= as a time we had both poolName & poolID. Same question as usual - is this an RFC 2119 SHOULD that helps with interop= eration, 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 collect= or wouldn't accept the log (however the collector would decide to do that). [Senthil2] As you see in the below template, if the mandatory field is Yes,= then the NAT device MUST log it. If the field is not mandatory, then the n= at device can choose to send it or not. But the actual template will that t= he device sends indicates what the device is sending and the data set will = correspond to the template, and the collector will correlate the template a= nd the data sets. If it's not an RFC 2119 SHOULD, but just implementation guidance, the expla= nation you provided would be more helpful (something like "could include a = pool name, but some NAT engines are implemented in hardware that lacks stri= ng processing capability, and these are permitted to substitute a poolID. T= here'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", . [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: +1 919 392 5158 Renaldo Penno Cisco Systems 170 W Tasman Drive San Jose, California 95035 USA Email: repenno@cisco.com Sivakumar & Penno Expires August 15, 2014 [Page 21] --_000_CFAA34BB106C60ssenthilciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <12465753C6F1454BAF9B301C472A7286@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Spencer,

Thanks for your comments again, please see inline [Senthil2].

From: Spencer Dawkins <spencerdawkins.ietf@gmail.com= >
Date: Friday, May 23, 2014 5:05 PM<= br> To: Senthil Sivakumar <ssenthil@cisco.com>, "draft-ietf-beha= ve-ipfix-nat-logging@tools.ietf.org" <draft-ietf-behave-ipfix-nat-lo= gging@tools.ietf.org>
Cc: "behave@ietf.org" <= behave@ietf.org>
Subject: Re: AD Evaluation of draft= -ietf-behave-ipfix-nat-logging-03

On 05/02/2014 02:20 PM, Senthil Sivakumar (s= senthil) wrote:

Hi Spencer,

Thanks for the thorough review.

Please see inline for [Senthil]. If you agree, I will submit another v= ersion fixing all the issues raised and agreed upon. I will wait for your r= esponse.

Hi, Senthil,

Thanks for being responsive!

Just as a high-order bit, many of the questions I asked are whether the dra= ft uses "required" to mean "this is the way it works" -= there's a difference between "the sender transmits a log" and &q= uot;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 whe= re it is
   actually required for interoperation or to limit behavior whic= h has
   potential for causing harm (e.g., limiting retransmisssions)&n= bsp; For
   example, they must not be used to try to impose a particular m= ethod
   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 exam= ples, 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 c= ontinuing source of controversy in the IETF, especially during cross-area r= eview - my suggestion is that you either change the requirements language s= tatement to include a statement about whether lower-case versions are intended as requirements language, or don't use th= e lower-case terms in the document.

I'll try to be clear in my detailed comments, but that's often what I'm try= ing to get at.

[Senthil2] Ok, thanks.

Thanks

Senthil

From: Spencer Dawkins <spencerdaw= kins.ietf@gmail.com>
Date: Thursday, May 1, 2014 4:25 PM=
To: "draft= -ietf-behave-ipfix-nat-logging@tools.ietf.org" <draft-ietf-behave-ipfix-nat-logging@tools.ietf.org>
Cc: "behave@ietf.org" <behave@ietf.org> Subject: AD Evaluation of draft-iet= f-behave-ipfix-nat-logging-03
Resent-From: <draft-alias-bo= unces@tools.ietf.org>
Resent-To: <repenno@cisco.com>, Sent= hil Sivakumar <ssenthil@cisco.com>
Resent-Date: Thursday, May 1, 2014 = 4:26 PM

Dear draft-ietf-behave-ipfix-nat-loggi= ng Authors,

I've completed my AD evaluation for this draft. I found some things I'd lik= e to see changed before proceeding, but most are editorial. Please take a l= ook, 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 delet= ion of
&nb= sp; ^^^^^^^^
SD: Is this required, like, legally required, or ? Is it more like "Op= erators need NAT devices to log events ..."?

[Senthil] : It is the later, the network operators require the NAT dev= ices to be able to log events.

We don't usually include requirements language in the Abstract (that happen= s later, which is fine in the document body).

The longer I look at this, the more I think it's something like "Opera= tors expect NAT devices to log events".

   translations and informat= ion about the resources it is managing. The
   logs are required in many cases to identify an attacker or a h= ost
   that was used to launch malicious attacks and/or for various o= ther
   purposes of accounting. Since there is no standard way o= f logging
   this information, different NAT devices behave differently and= hence
            &nb= sp;            =       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SD: Is this "different NAT devices log this information differently&qu= ot;?

[Senthil] Correct, as the sentenc= e says, "Since there is no standard way=85", 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 c= onsistent behavior. The lack of a
   consistent way makes it difficult to write the collector appli= cations
   that would receive this data and process it to present useful<= br>    information. This document describes the information tha= t 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 requirement= s that a NAT device should adhere to.

I know this seems tedious, but I'm not able to map what you provided as exp= lanation 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 informati= on.

I'm guessing that what you're saying is really "this document describe= s the information that logging NAT devices produce".

This doesn't matter yet (you're still in the abstract, which shouldn't be p= roviding requirements anyway), but in the body of the document, it needs to= be clear.

[Senthil2] : How about I revise the text as:

   Net=
work operators expect NAT devices to log events like creation and deletion =
of
   translations and information about the resources it is managing.  The
   logs are essential 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 log the information using propri=
etary formats

   and=
 hence it is difficult to expect a consistent behavior.  The lack of a
   consistent way to log the data makes it difficult to write the collector=
 applications
   that would receive this data and process it to present useful
   information.  This document describes the formats for logging of NAT eve=
nts.

2. Introduction

   The IPFIX Protocol [RFC5101bis] defines a generic push mechani= sm for
   exporting information and events. The IPFIX Information = Model
   [IPFIX-IANA] defines a set of standard Information Elements (I= Es)
   which can be carried by the IPFIX protocol. This documen= t details
   the IPFIX Information Elements(IEs) that are required for logg= ing by
   a NAT device. The document will specify the format of th= e IE's that
   are required to be logged by the NAT device and all the option= al
       ^^^^^^^^^^^^^^^^^^^^^
SD: Now that we're in the document body, if this is required, shouldn't the= re 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&q= uot;, 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 t= he 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 par= agraph about requirements language to say that case doesn't matter).

But "REQUIRED" is "MUST", so changing to "SHOULD&q= uot; would be a change in your intended meaning.

[Senthil2] I will change this to "are REQUIRED".

   This document and [I-D.be= have-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 wi= th the MIB revision?

[Senthil2] Not directly, but there is some overlap of information that= can be obtained by using a MIB and the logging mechanisms.

3. Scope

   This document provides the information model to be used for lo= gging
   the NAT devices including Carrier Grade NAT (CGN) events. = ; This
            &nb= sp;      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<= br> SD: This sentence seems somewhat turned around - "logging events"= , not "logging the NAT devices".

[Senthil] Agree, I will change th= is 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 proto= col
   like TCP, UDP or SCTP that is to be used to log NAT events.&nb= sp; The log
   events SHOULD NOT be lost but the choice of the actual transpo= rt
   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 outsi= de the scope of the document ...

[Senthil] Are you objecting to the second part of the last sentence &q= uot;the choice of actual transport=85", I think the requirement is tha= t 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 o= f a transport protocol", but then provided a requirement about the imp= lications 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 u= sually expects from transport protocols, so please be patient.

First, I'm confused by the SHOULD with no qualification. When is it OK to l= ose LOG events?

[Senthil] Ideally you should never lose the logs, but if the box crash= es or an irrecoverable error happens.

Second, you're not giving guidance on selecting a transport protocol, but y= ou are giving guidance about expecting a reliable data channel, whether MUS= T be reliable or SHOULD be reliable. Are there other transport characterist= ics that you expect? For instance, is in-order delivery assumed? Is duplicate detection by IPFIX assumed (if = a log arrives twice, does IPFIX notice)?

[Senthil2] There is no need for in-order delivery, the collector shoul= d be able to detect two identical events at the exact same time stamp as du= plicates. The only transport characteristic required is the reliability.&nb= sp;

Third, are IPFIX implementations so transport protocol-agnostic that if my = NAT device decides to to send logs using SCTP with partial reliability, I s= hould expect that to work with any collector that implements this specifica= tion?

[Senthil2] One of the reasons for not giving the guidance is that IPFI= X was initially SCTP only but in the latest RFC 7011, IPFIX can be transpor= ted using TCP/UDP/SCTP and others. As long as both the devices are using IP= FIX,

and the receiving collector is able to parse and understand SCTP, it s= hould work. There is a little bit of configuration required, I would think,= to tell the NAT device on what protocol and port to use, to specify where = the collector is

listening.

It happens that I co-chaired MEDIACTRL when the specification said "TC= P or SCTP", and got feedback during AD evaluation that if we didn't pi= ck a mandatory to implement transport protocol, that wouldn't guarantee int= eroperation between two standard-conforming devices.

[Senthil2] Ok, I don=92t know if in this case, I could pick a transpor= t protocol to use with IPFIX, since IPFIX allows that flexibility and NAT l= ogs are transported over IPFIX, people would expect that we support all the= transport protocols that IPFIX supports. Let me know if you have better suggestions on what the guidance should be.=

   The existing IANA IPFIX IEs registry [IPFIX-IANA] already has<= br>    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 elem= ents is

SD: I got lost on "these elements" - is that "the elements i= n the existing registry"

[Senthil] Yes. How about "Ra= ther, the information elements as defined in the IPFIX-IANA registry is wit= hin the scope of this document"?

I think that's "are withi= n", but yes, that works. Thanks.

   within the scope of this docu= ment.

   This document assumes that the NAT device will use the existin= g 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 bey= ond the
   scope of this document.

   The optimization of logging the NAT events are left to the
            &nb= sp;            =             &nb= sp;        ^^^
   implementation and are beyond the scope of this document.
            &nb= sp;         ^^^
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 v= ery
   efficient. IPFIX based logging is recommended for enviro= nments where
   a high volume of logging is required, for example, where per-f= low
   logging is needed. However, IPFIX based logging requires= a collector
   that processes the binary data and requires a network manageme= nt
   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 re= lates
            &nb= sp;            =             &nb= sp;         ^^^^^^^^^
SD: Is this "a state transition"? I found "a happening"= somewhat odd.

[Senthil] Yes, I can rephrase thi= s as "viewed as a state transition as it relates to" or "vie= wed as an action as it relates to", if that is ok.

If "a state transition" is correct, I'd prefer that (if it's corr= ect :-) ).

   to the management of NAT reso= urces. 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 flowi= ng
   through the NAT device or through an external entity installin= g
   policies on the NAT router or as a result of an asynchronous e= vent
   like a timer. The list of events are provided in Section= 4.1. Each
   of these events SHOULD be logged, unless they are administrati= vely
   prohibited. A NAT device MAY log these events to multipl= e collectors
   if redundancy is required. The network administrator wil= l specify
   the collectors to which the log records are to be sent.

   A collector may receive NAT events from multiple CGN devices a= nd
   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. T= he 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 i= s a collector that some application writer will

develop.

Don't you think you can levy requirements about that on the collector? I do= n't understand.

[Senthil2] This document was written for how the NAT devices should se= nd their logs and their formats. I am not sure if I am opening a can of wor= ms, by

Starting to specify what the collector should do as part of this docum= ent.

But beyond that, what I THINK the text is saying, is that multiple CGN devi= ces can ("may") send to a single collector,

[Senthil2] Yes.

that none of the CDN devices have= to have a unique source ID to identify themselves ("should", but= not "must"),

^^^^^

[Senthil2] No, that is not what the text is saying . In fact it says t= he opposite,

"Each CGN device should have a unique s=
ource ID to identify themselves."

and that the collector is still e= xpected to be able to distinguish among logs coming from multiple CGNs (&qu= ot;should").

[Senthil2] Yes, the collector should be able to distinguish the record= s coming in from distinct sources. This is a generic IPFIX requirement,

That a collector is able to handle multiple sources. Maybe I should re= move this text on the collector as it seems to cause more confusion?

Am I misreading this?

If not, do you think that works?

[Senthil2] Please see above, let me know if I misunderstood what you w= ere asking.

   is part of the IPFIX template= and data exchange.

   Prior to logging any events, the NAT device MUST send the temp= late of
   the record to the collector to advertise the format of the dat= a
   record that it is using to send the events. The template= s can be
   exchanged as frequently as required given the reliability of t= he
   connection. There SHOULD be a configurable timer for con= trolling the
   template refresh. NAT device SHOULD combine as many even= ts 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 dis= cussed
   in [RFC6302] and [RFC6888]. Logging of destination infor= mation
   increases the size of each record and increases the need for s= torage
   considerably. It increases the number of log events gene= rated
   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 an= d hence
   should be done with caution. However, this draft provide= s the
   necessary fields to log the destination information in cases w= here
   they are required to be logged.

5.2. Information Elements

   The templates could contain a subset of the Information Elemen= ts(IEs)
   shown in Table 1 depending upon the event being logged. = For example
   a NAT44 session creation template record will contain,
            &nb= sp;            =             &nb= sp;      ^^^^
SD: Is this the only possible NAT44 template? If so, fine, but if not, perh= aps "could contain", or "typically contains"?

[Senthil] Yes, this is all the in= formation 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.

[Senthil2] I think this is the base information required, but difficul= t to predict what will be added in the future, so I am going to leave it as= is, unless you have objection.

   {sourceIPv4Adress, postNATSou= rceIPv4Address, destinationIpv4Address,
   postNATDestinationIPv4Address, sourceTransportPort,
   postNAPTSourceTransportPort, destinationTransportPort,
   postNAPTDestTransportPort, internalAddressRealm, natEvent, tim= eStamp}

   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, 14= 800,
   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 w= ould
   need to export the events. The formats of the IE's and t= he 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-element= s 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 somet= hing that already existed in the IPFIX registry rather than asking for a ne= w 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 d= escription that is called observationTimeMilliSeconds". The other fiel= d 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=92t stick to the= same terminology, so I don=92t 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 s= hould 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 I= PFIX review team. Could you just add a note pointing this question out, and= asking if they have any suggestions?

[Senthil2] I will send out an email to the IPFIX mailing list and to t= he people who reviewed it from the IPFIX WG.

   +--------------------= --------------+--------+-------+---------------+
   |          &= nbsp; Field Name          = ; |   Size | IANA | Description |
   |          &= nbsp;           &nbs= p;           | (bits) | I= PFIX |           &nb= sp;   |
   |          &= nbsp;           &nbs= p;           |  = ;      |    ID |   &= nbsp;           |
   +----------------------------------+--------+-----= --+---------------+
   |          &= nbsp; timeStamp          =    |     64 |   323 | System = Time |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   when the   |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;    event     |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   occured.   |
   |          natIns= tanceId           | =     32 |   TBD | NAT Instance |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; Identifier |
   |          &= nbsp;   vlanID        &nb= sp;     |     16 |   = ; 58 |   VLAN ID in |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   case of    |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; overlapping |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   networks   |
   |           = ingressVRFID           |&= nbsp;    32 |   234 |   VRF ID in &= nbsp; |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   case of    |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; overlapping |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   networks   |
   |        sourceIPv4Address&= nbsp;        |     3= 2 |     8 | Source IPv4 |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   Address    |
   |     postNATSourceIPv4Address  =    |     32 |   225 |   T= ranslated |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; Source IPv4 |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   Address    |
   |        protocolIdentifier=         |      = 8 |     4 |   Transport   |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   protocol   |
   |       sourceTransportPort = ;       |     16 | &= nbsp;   7 | Source Port |
   |   postNAPTsourceTransportPort    |&= nbsp;    16 |   227 |   Translated = |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; Source port |
   |      destinationIPv4Address &n= bsp;    |     32 |    12 = | Destination |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; IPv4 Address |
   | postNATDestinationIPv4Address   |  = ;   32 |   226 |   Translated |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;     IPv4     |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; destination |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   address    |
   |     destinationTransportPort  =    |     16 |    11 | De= stination |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;     port     |
   | postNAPTdestinationTransportPort |     1= 6 |   228 |   Translated |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; Destination |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;     port     |
   |        sourceIPv6Address&= nbsp;        |     2= 7 |   128 | Source IPv6 |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   address    |
   |      destinationIPv6Address &n= bsp;    |    128 |    28 |&nbs= p; Destination |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; IPv6 address |
   |     postNATSourceIPv6Address  =    |    128 |   281 |   Transl= ated |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; source IPv6 |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;   addresss   |
   | postNATDestinationIPv6Address   |  = ; 128 |   282 |   Translated |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; Destination |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; IPv6 address |
   |       internalAddressRealm&nbs= p;      |      8 | &= nbsp; 229 |     Source    |
   |          &= nbsp;           &nbs= p;           |  = ;      |       | Add= ress Realm |
   |       externalAddressRealm&nbs= p;      |      8 | &= nbsp; TBD | Destination |
   |          &= nbsp;           &nbs= p;           |  = ;      |       | Add= ress Realm |
   |          &= nbsp; natEvent         &= nbsp;   |      8 |   230 | Typ= e of Event |
   |          portRa= ngeStart          |  = ;   16 |   361 |   Allocated   |    |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; port block |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;    start     |
   |           = portRangeEnd           |&= nbsp;    16 |   362 |   Allocated &= nbsp; |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; Port block |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p;     end      |
   |          &= nbsp; natPoolID          =    |     32 |   283 |  &n= bsp; NAT pool   |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; Identifier |
   |          natLim= itEvent           | =     32 |   TBD | Limit event |
   |          &= nbsp;           &nbs= p;           |  = ;      |       |&nbs= p; identifier |
   +----------------------------------+--------+-----= --+---------------+

            &nb= sp;         Table 1: Template forma= t Table

5.3. Definition of NAT Events

   The following are the list of NAT events and the proposed even= t
   values. The list can be expanded in the future as necess= ary. The
   data record will have the corresponding natEvent value to iden= tify
   the event that is being logged.

            &nb= sp;      +--------------------------+-----= ---+
            &nb= sp;      |      &nbs= p; Event Name        | Values |
            &nb= sp;      +--------------------------+-----= ---+
            &nb= sp;      |   NAT44 Session create &= nbsp; |      1 |
            &nb= sp;      |   NAT44 Session delete &= nbsp; |      2 |
            &nb= sp;      | NAT Addresses exhausted | &n= bsp;    3 |
            &nb= sp;      |   NAT64 Session create &= nbsp; |      4 |
            &nb= sp;      |   NAT64 Session delete &= nbsp; |      5 |
            &nb= sp;      |     NAT44 BIB creat= e     |      6 |
            &nb= sp;      |     NAT44 BIB delet= e     |      7 |
            &nb= sp;      |     NAT64 BIB creat= e     |      8 |
            &nb= sp;      |     NAT64 BIB delet= e     |      9 |
            &nb= sp;      |   NAT ports exhausted &n= bsp; |     10 |
            &nb= sp;      |      Quota exc= eeded      |     11 |
            &nb= sp;      | Address binding create |&nb= sp;    12 |
            &nb= sp;      | Address binding delete |&nb= sp;    13 |
            &nb= sp;      | Port block allocation  = |     14 |
            &nb= sp;      | Port block de-allocation |  &= nbsp; 15 |
            &nb= sp;      |    Threshold reached&nbs= p;    |     16 |
            &nb= sp;      +--------------------------+-----= ---+

            &nb= sp;           Table 2: NA= T Event ID table

5.4. Quota exceeded Event types

   The following table shows the sub event types for the Quota ex= ceeded
   or limits reached event. The events that can be reported= are the
   Maximum session entries limit reached, Maximum BIB entries lim= it
   reached, Maximum session/BIB entries per user limit reached an= d
   maximum subscribers or hosts limit reached.

            +---= ------------------------------------+--------+
            | &= nbsp;     Quota Exceeded Event Name   &n= bsp;   | Values |
            +---= ------------------------------------+--------+
            | &= nbsp;      Maximum Session entries  &nbs= p;     |      1 |
            | &= nbsp;        Maximum BIB entries &n= bsp;        |    &nb= sp; 2 |
            | &= nbsp;      Maximum entries per user  &nb= sp;    |      3 |
            | = Maximum active hosts or subscribers |      4= |
            | = Maximum fragments pending reassembly |      5 |             +---= ------------------------------------+--------+

            &nb= sp;       Table 3: Quota Exceeded event table=

5.5. Threshold reached Event types

   The following table shows the sub event types for the threshol= d
   reached event. The administrator can configure the thres= holds and
   whenever the threshold is reached or exceeded, the correspondi= ng
   events are generated.

   The address pool high threshold event will be reported when th= e
   address pool reaches a high water mark as defined by the opera= tor.
   This will sever as an indication that the operator might have = to add
   more addresses to the pool or an indication that the subsequen= t 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 genera= ted
   when a single user uses more address and port mapping than a    configured threshold.

   +---------------------------------------------------------= +--------+
   |          &= nbsp;   Threshold Exceeded Event Name    &nbs= p;         | Values |
   +---------------------------------------------------------= +--------+
   |          &= nbsp; Address pool high threshold event      =       |      1 |
   |          &= nbsp; Address pool low threshold event     &= nbsp;      |      2 |
   |      Address and port mapping high = threshold event      |    &nbs= p; 3 |
   | Address and port mapping per user high threshold event= |      4 |
   |       Global Address mapping h= igh threshold event       |   =    5 |
   +---------------------------------------------------------= +--------+

            &nb= sp;         Table 4: Threshold even= t table

5.6. Templates for NAT Events

   The following is the template of events that will have to logg= ed.
            &nb= sp;            =             &nb= sp;          ^^^^^^^^^^^^^^^^^= ^^

SD: I think this is a nit, but the sentence is garbled. "will be logge= d"?

   The events below are identified at the time of this writing bu= t the
   events are expandable. Depending on the implementation a= nd
   ^^^^^^^^^^^^^^^^^^^^^
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 wil= l 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 re= quired
   by [RFC6888]. However, when the destination information = is
   suppressed, the session log event contains the same informatio= n as
   the BIB event. In such cases, the NAT device SHOULD NOT = send both
   BIB and session events.

      +----------------------------------+= -------------+-----------+
      |       &= nbsp;    Field Name       = ;     | Size (bits) | Mandatory |
      +----------------------------------+= -------------+-----------+
      |       &= nbsp;    timeStamp       =       |       &= nbsp; 64 |    Yes    |
      |       &= nbsp; natInstanceID        &n= bsp; |          32 |&nbs= p;    No    |
      |       vlanID= /ingressVRFID        |   =        32 |     No &= nbsp; |
      |        = sourceIPv4Address         | &n= bsp;        32 |    Yes&n= bsp;   |
      |     postNATSourceIPv4A= ddress     |       &= nbsp; 32 |    Yes    |
      |        = protocolIdentifier        |  &= nbsp;        8 |    Yes&n= bsp;   |
      |       source= TransportPort        |   =        16 |    Yes  = |
      |   postNAPTsourceTransportPort&nb= sp;   |          16 = |    Yes    |
      |      destinationI= Pv4Address      |     &nb= sp;    32 |     No    |       | postNATDestinationIPv4Address &= nbsp; |          32 | &nb= sp;   No    |
      |     destinationTranspo= rtPort     |       &= nbsp; 16 |     No    |
      | postNAPTdestinationTransportPort | &n= bsp;        16 |    = No    |
      |       intern= alAddressRealm       |    = ;       8 |     No &= nbsp; |
      |       extern= alAddressRealm       |    = ;       8 |     No &= nbsp; |
      |       &= nbsp;     natEvent      &= nbsp;      |      &n= bsp;    8 |    Yes    |
      +----------------------------------+= -------------+-----------+

            &nb= sp; 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.

      +----------------------------------+= -------------+-----------+
      |       &= nbsp;    Field Name       = ;     | Size (bits) | Mandatory |
      +----------------------------------+= -------------+-----------+
      |       &= nbsp;    timeStamp       =       |       &= nbsp; 64 |    Yes    |
      |       &= nbsp; natInstanceID        &n= bsp; |          32 |&nbs= p;    No    |
      |       vlanID= /ingressVRFID        |   =        32 |     No &= nbsp; |
      |        = sourceIPv6Address         | &n= bsp;       128 |    Yes &= nbsp; |
      |     postNATSourceIPv4A= ddress     |       &= nbsp; 32 |    Yes    |
      |        = protocolIdentifier        |  &= nbsp;        8 |    Yes&n= bsp;   |
      |       source= TransportPort        |   =        16 |    Yes  = |
      |   postNAPTsourceTransportPort&nb= sp;   |          16 = |    Yes    |
      |      destinationI= Pv6Address      |     &nb= sp;   128 |     No    |
      | postNATDestinationIPv4Address &= nbsp; |          32 | &nb= sp;   No    |
      |     destinationTranspo= rtPort     |       &= nbsp; 16 |     No    |
      | postNAPTdestinationTransportPort | &n= bsp;        16 |    = No    |
      |       intern= alAddressRealm       |    = ;       8 |     No &= nbsp; |
      |       extern= alAddressRealm       |    = ;       8 |     No &= nbsp; |
      |       &= nbsp;     natEvent      &= nbsp;      |      &n= bsp;    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 crea= ted or
   deleted. The following is a template of the event.

         +---------------------= --------+-------------+-----------+
         |    &= nbsp;     Field Name      = ;   | Size (bits) | Mandatory |
         +---------------------= --------+-------------+-----------+
         |    &= nbsp;     timeStamp      =     |          = 64 |    Yes    |
         |    &= nbsp;   natInstanceID        |=           32 |  &nbs= p; No    |
         |     = vlanID/ingressVRFID     |     =      32 |     No    = |
         |    &= nbsp; sourceIPv4Address      |   &n= bsp;      32 |    Yes  &n= bsp; |
         |   postNATSourc= eIPv4Address |          = 32 |    Yes    |
         |    &= nbsp; protocolIdentifier     |    &= nbsp;      8 |     No &nb= sp; |
         |     = sourceTransportPort     |     =      16 |     No    = |
         | postNAPTsourceTransportP= ort |          16 |  = ;   No    |
         |     = internalAddressRealm    |      = ;     8 |     No    = |
         |     = externalAddressRealm    |      = ;     8 |     No    = |
         |    &= nbsp;      natEvent     &= nbsp;    |        &n= bsp; 8 |    Yes    |
         +---------------------= --------+-------------+-----------+

            &nb= sp; 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 crea= ted or
   deleted. The following is a template of the event.

         +---------------------= --------+-------------+-----------+
         |    &= nbsp;     Field Name      = ;   | Size (bits) | Mandatory |
         +---------------------= --------+-------------+-----------+
         |    &= nbsp;     timeStamp      =     |          = 64 |    Yes    |
         |    &= nbsp;   natInstanceID        |=           32 |  &nbs= p; No    |
         |     = vlanID/ingressVRFID     |     =      32 |     No    = |
         |    &= nbsp; sourceIPv6Address      |   &n= bsp;     128 |    Yes    = |
         |   postNATSourc= eIPv4Address |          = 32 |    Yes    |
         |    &= nbsp; protocolIdentifier     |    &= nbsp;      8 |     No &nb= sp; |
         |     = sourceTransportPort     |     =      16 |     No    = |
         | postNAPTsourceTransportP= ort |          16 |  = ;   No    |
         |     = internalAddressRealm    |      = ;     8 |     No    = |
         |     = externalAddressRealm    |      = ;     8 |     No    = |
         |    &= nbsp;      natEvent     &= nbsp;    |        &n= bsp; 8 |    Yes    |
         +---------------------= --------+-------------+-----------+

            &nb= sp; 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 glo= bal
   IPv4 addresses in a given pool of addresses. Typically, = this event
   would mean that the NAT device wont be able to create any new<= br>             &nb= sp;            =          ^^^^
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 eith= er 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 th= is in the hardware that lacks the string processing capability.

OK, that helps. I'm understanding that a different template might have incl= uded a pool name, but not a poolID, is that right?

I'm somewhat uneasy about the "either should be logged, but not both&q= uot; text.

[Senthil2] That text is not relevant anymore and should be removed, th= ere was a time we had both poolName & poolID.

Same question as usual - is this an RFC 2119 SHOULD that helps with interop= eration, 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 collect= or wouldn't accept the log (however the collector would decide to do that).=

[Senthil2] As you see in the below template, if the mandatory field is= Yes, then the NAT device MUST log it. If the field is not mandatory, then = the nat device can choose to send it or not. But the actual template will t= hat the device sends indicates what the device is sending and the data set will correspond to the template, an= d the collector will correlate the template and the data sets.

If it's not an RFC 2119 SHOULD, but just implementation guidance, the expla= nation you provided would be more helpful (something like "could inclu= de 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").

      &n= bsp;         +---------------&#= 43;-------------+-----------+
            &nb= sp;   |   Field Name | Size (bits) | Mandatory |<= br>             &nb= sp;   +---------------+-------------+-----------+=
            &nb= sp;   |   timeStamp   |   &nbs= p;      64 |    Yes  &nbs= p; |
            &nb= sp;   | natInstanceID |       =    32 |     No    |
            &nb= sp;   |    natEvent   |   = ;        8 |    Yes =    |
            &nb= sp;   |   natPoolID   |   &nbs= p;      32 |    Yes  &nbs= p; |
            &nb= sp;   +---------------+-------------+-----------+=

            &nb= sp;    Table 9: Address Exhausted event template

5.6.6. Ports Exhausted event

   This event will be generated when a NAT device runs out of por= ts for
   a global IPv4 address. Port exhaustion shall be reported= per
   protocol (UDP, TCP etc). This event SHOULD be rate limit= ed as many
   packets hitting the device at the same time will trigger a bur= st of
   port exhausted events.

   The following is a template of the event.

          +---------------= -----------+-------------+-----------+
          |   &= nbsp;    Field Name       = ; | Size (bits) | Mandatory |
          +---------------= -----------+-------------+-----------+
          |   &= nbsp;    timeStamp       = |          64 | &n= bsp; Yes    |
          |   &= nbsp; natInstanceID       |  =         32 |     No&= nbsp;   |
          |   &= nbsp;     natEvent      &= nbsp; |           8= |    Yes    |
          | postNATSourceIPv4A= ddress |          32 | &n= bsp; Yes    |
          |    = protocolIdentifier    |      &= nbsp;    8 |    Yes    |
          +---------------= -----------+-------------+-----------+

            &nb= sp;    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.&n= bsp; The
   quota exceeded event templates are described below
            &nb= sp;            =             &nb= sp;            =    ^
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 follow= ing is the
   template of the event.

            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    Field Name   | Size (bits) | Mandat= ory |
            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    timeStamp    |  &nbs= p;       64 |    Yes &nbs= p; |
            &nb= sp; | natInstanceID |      =     32 |     No    |
            &nb= sp; |     natEvent    |  = ;         8 |    Yes=     |
            &nb= sp; | natLimitEvent |      =     32 |    Yes    |
            &nb= sp; | configuredLimit |       &nbs= p; 32 |    Yes    |
            &nb= sp; +-----------------+-------------+-----------+

             Ta= ble 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 follow= ing is the
   template of the event.

            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    Field Name   | Size (bits) | Mandat= ory |
            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    timeStamp    |  &nbs= p;       64 |    Yes &nbs= p; |
            &nb= sp; | natInstanceID |      =     32 |     No    |
            &nb= sp; |     natEvent    |  = ;         8 |    Yes=     |
            &nb= sp; | natLimitEvent |      =     32 |    Yes    |
            &nb= sp; | configuredLimit |       &nbs= p; 32 |    Yes    |
            &nb= sp; +-----------------+-------------+-----------+

            &nb= sp; 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.

           +---------= ------------+-------------+---------------+
           |  &= nbsp;   Field Name     | Size (bits) | &= nbsp; Mandatory   |
           +---------= ------------+-------------+---------------+
           |  &= nbsp;   timeStamp      |  &nbs= p;       64 |      Y= es      |
           |  &= nbsp; natInstanceID    |      =     32 |       No  &= nbsp;   |
           |  &= nbsp;    natEvent      |  = ;         8 |   &nbs= p; Yes      |
           |  &= nbsp; natLimitEvent    |      =     32 |      Yes   =    |
           |   = configuredLimit   |       &nbs= p; 32 |      Yes    &nbs= p; |
           | vlanID/ingre= ssVRFID |          32 | &= nbsp;     No      |
           | source= IPv4 address |          32 | Y= es for NAT44 |
           | source= IPv6 address |         128 | Yes fo= r 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.&nbs= p; The
   following is the template of the event.

            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    Field Name   | Size (bits) | Mandat= ory |
            &nb= sp; +-----------------+-------------+-----------+
            &nb= sp; |    timeStamp    |  &nbs= p;       64 |    Yes &nbs= p; |
            &nb= sp; | natInstanceID |      =     32 |     No    |
            &nb= sp; |     natEvent    |  = ;         8 |    Yes=     |
            &nb= sp; | natLimitEvent |      =     32 |    Yes    |
            &nb= sp; | configuredLimit |       &nbs= p; 32 |    Yes    |
            &nb= sp; +-----------------+-------------+-----------+

        Table 14: Maximum hosts/subscrib= ers 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.

          +---------------= -------+-------------+---------------+
          |   &= nbsp; Field Name      | Size (bits) | &= nbsp; Mandatory   |
          +---------------= -------+-------------+---------------+
          |   &= nbsp; timeStamp       |  &nbs= p;       64 |      Y= es      |
          |    = natInstanceID     |      =     32 |       No  &= nbsp;   |
          |   &= nbsp;   natEvent       |  = ;         8 |   &nbs= p; Yes      |
          |    = natLimitEvent     |      =     32 |      Yes   =    |
          |   config= uredLimit    |       &nbs= p; 32 |      Yes    &nbs= p; |
          | internalAddressRea= lm |           8 | &= nbsp;    Yes      |
          | vlanID/ingressVRFI= D |          32 | &= nbsp;     No      |
          | sourceIPv4 a= ddress |          32 | Y= es for NAT44 |
          | sourceIPv6 a= ddress |         128 | Yes fo= r NAT64 |
          +---------------= -------+-------------+---------------+

       Table 15: Maximum fragments pending re= assembly Exceeded event
            &nb= sp;            =         template

5.6.8. Threshold reached events

   This event will be generated when a NAT device reaches a opera= tor
   configured threshold when allocating resources. The thre= shold
   reached events are described in the section above. The f= ollowing 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 reac= hed for
   the address pool. The template is the same for both high= and low
   threshold events

            &nb= sp; +-------------------+-------------+-----------+
            &nb= sp; |     Field Name    | Size (bits) | = Mandatory |
            &nb= sp; +-------------------+-------------+-----------+
            &nb= sp; |     timeStamp     | &nbs= p;        64 |    Yes&nbs= p;   |
            &nb= sp; |   natInstanceID   |     =      32 |     No    = |
            &nb= sp; |      natEvent     | = ;          8 |  &nbs= p; Yes    |
            &nb= sp; | natThresholdEvent |        &n= bsp; 32 |    Yes    |
            &nb= sp; |     natPoolID     | &nbs= p;        32 |    Yes&nbs= p;   |
            &nb= sp; | configuredLimit |      &nbs= p;   32 |    Yes    |
            &nb= sp; +-------------------+-------------+-----------+

     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.

            &nb= sp; +-------------------+-------------+-----------+
            &nb= sp; |     Field Name    | Size (bits) | = Mandatory |
            &nb= sp; +-------------------+-------------+-----------+
            &nb= sp; |     timeStamp     | &nbs= p;        64 |    Yes&nbs= p;   |
            &nb= sp; |   natInstanceID   |     =      32 |     No    = |
            &nb= sp; |      natEvent     | = ;          8 |  &nbs= p; Yes    |
            &nb= sp; | natThresholdEvent |        &n= bsp; 32 |    Yes    |
            &nb= sp; | configuredLimit |      &nbs= p;   32 |    Yes    |
            &nb= sp; +-------------------+-------------+-----------+

       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.

           +---------= ------------+-------------+---------------+
           |  &= nbsp;   Field Name     | Size (bits) | &= nbsp; Mandatory   |
           +---------= ------------+-------------+---------------+
           |  &= nbsp;   timeStamp      |  &nbs= p;       64 |      Y= es      |
           |  &= nbsp; natInstanceID    |      =     32 |       No  &= nbsp;   |
           |  &= nbsp;    natEvent      |  = ;         8 |   &nbs= p; Yes      |
           | natThr= esholdEvent |          3= 2 |      Yes      |
           |   = configuredLimit   |       &nbs= p; 32 |      Yes    &nbs= p; |
           | vlanID/ingre= ssVRFID |          32 | &= nbsp;     No      |
           | source= IPv4 address |          32 | Y= es for NAT44 |
           | source= IPv6 address |         128 | Yes fo= r NAT64 |
           +---------= ------------+-------------+---------------+

   Table 18: Per-user Address port high threshold reached event t= emplate

5.6.8.4. Global Address mapping high threshold reached

   This event is generated when the high is reached for the per-u= ser
   address pool and ports. This is generated only by NAT de= vices that
   use a address pooling behavior of paired.

             &#= 43;---------------------+-------------+-----------+
             |&= nbsp;     Field Name     | Size (bi= ts) | Mandatory |
             &#= 43;---------------------+-------------+-----------+
             |&= nbsp;     timeStamp      |&nbs= p;         64 |    Y= es    |
             |&= nbsp;   natInstanceID    |    =       32 |     No  &= nbsp; |
             |&= nbsp;      natEvent      = |           8 | &nbs= p; Yes    |
             |&= nbsp; natThresholdEvent |       &n= bsp; 32 |    Yes    |
             |&= nbsp; configuredLimit   |     &nbs= p;    32 |    Yes    |
             | = vlanID/ingressVRFID |         = 32 |     No    |
             &#= 43;---------------------+-------------+-----------+

       Table 19: Global Address mapping high = threshold reached event
            &nb= sp;            =         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 f= reed.
   This binding event happens when the first packet of the first = flow
   from a host in the private realm.

     +--------------------------------+--------= -----+---------------+
     |        &= nbsp; Field Name         = ; | Size (bits) |   Mandatory   |
     +--------------------------------+--------= -----+---------------+
     |        &= nbsp; timeStamp         =    |          64 |&n= bsp;     Yes      |
     |         = natInstanceID          | =          32 |   &nbs= p;   No      |
     |        &= nbsp;   natEvent        &= nbsp;   |         &n= bsp; 8 |      Yes      |<= br>      |       sourceIPv4 a= ddress       |     &= nbsp;    32 | Yes for NAT44 |
     |       sourceIPv6 a= ddress       |     &= nbsp;   128 | Yes for NAT64 |
     | Translated Source IPv4 Address |  &nbs= p;       32 |      Y= es      |
     +--------------------------------+--------= -----+---------------+

            &nb= sp;     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-al= locates
   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 potentia= lly to
   limit the number of connections a subscriber is allowed to use= . In
   the following Port Block allocation template, the portRangeSta= rt and
   portRangeEnd must be specified.

Sivakumar & Penno        Expires Aug= ust 15, 2014          &nb= sp;    [Page 17]

Internet-Draft          IPFIX = IEs for NAT logging          F= ebruary 2014

   It is up to the implementation to choose to consolidate log re= cords
   in case two consecutive port ranges for the same user are allo= cated
   or freed.

     +--------------------------------+--------= -----+---------------+
     |        &= nbsp; Field Name         = ; | Size (bits) |   Mandatory   |
     +--------------------------------+--------= -----+---------------+
     |        &= nbsp; timeStamp         =    |          64 |&n= bsp;     Yes      |
     |         = natInstanceID          | =          32 |   &nbs= p;   No      |
     |        &= nbsp;   natEvent        &= nbsp;   |         &n= bsp; 8 |      Yes      |<= br>      |       sourceIPv4 a= ddress       |     &= nbsp;    32 | Yes for NAT44 |
     |       sourceIPv6 a= ddress       |     &= nbsp;   128 | Yes for NAT64 |
     | Translated Source IPv4 Address |  &nbs= p;       32 |      Y= es      |
     |         = portRangeStart         |  = ;        16 |    &nb= sp; Yes      |
     |        &= nbsp; portRangeEnd          |&= nbsp;         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 sho= uld be
   logged SHOULD be the same irrespective of what kind of encodin= g
   scheme is used. IPFIX is chosen because is it an IETF st= andard that
   meets all the needs for a reliable logging mechanism. IP= FIX provides
   the flexibility to the logging device to define the data sets = that it
   is logging. The IEs specified for logging MUST be the sa= me
   irrespective of the encoding mechanism used.

7. Acknowledgements

   Thanks to Dan Wing, Selvi Shanmugam, Mohamed Boucadir, Jacni Q= in
   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 IPF= IX
   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 fir= st covers
   requirements applicable to log management in general. An= y additional
   standardization required to fullfil these requirements is out = of
   scope of the present document. Some management considera= tions is
   covered in [I-D.behave-syslog-nat-logging]. This documen= t covers the
   additional considerations.

9.1. Ability to collect events from multiple NAT devices

   An IPFIX collector should be able to collect events from multi= ple NAT
   devices and be able to decipher events based on the sourceID i= n the
   IPFIX header.

9.2. Ability to suppress events

   The exhaustion events can be overwhelming during traffic burst= s and
   hence should be handled by the NAT devices to rate limit them = before
   sending them to the collectors. For eg. when the port ex= haustion
   happens during bursty conditions, instead of sending a port    exhaustion event for every packet, the exhaustion events shoul= d 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 t= o Indicate
            &nb= sp; Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2663] Srisuresh, P. and M. Holdrege, "IP Networ= k Address
            &nb= sp; Translator (NAT) Terminology and Considerations", RFC
            &nb= sp; 2663, August 1999.

   [RFC4787] Audet, F. and C. Jennings, "Network Addre= ss Translation
            &nb= sp; (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
            &nb= sp; RFC 4787, January 2007.

   [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S.,= and P.
            &nb= sp; Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,             &nb= sp; RFC 5382, October 2008.

   [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum,= "Stateful
            &nb= sp; NAT64: Network Address and Protocol Translation from IPv6
            &nb= sp; Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. She= ppard,
            &nb= sp; "Logging Recommendations for Internet-Facing Servers", BCP             &nb= sp; 162, RFC 6302, June 2011.

   [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nak= agawa, A.,
            &nb= sp; and H. Ashida, "Common Requirements for Carrier-Grade NATs
            &nb= sp; (CGNs)", BCP 127, RFC 6888, April 2013.

11.2. Informative References

   [I-D.ietf-behave-syslog-nat-logging]
            &nb= sp; Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog
            &nb= sp; Format for NAT Logging", draft-ietf-behave-syslog-nat-
            &nb= sp; logging-06 (work in progress), January 2014.

   [IPFIX-IANA]
            &nb= sp; IANA, "IPFIX Information Elements registry",
            &nb= sp; <http://www.iana.org/assignments/ipfix>.

   [RFC5101bis]
            &nb= sp; Claise, B. and B. Trammel, "Specification of the IP Flow
            &nb= sp; Information eXport (IPFIX) Protocol for the Exchange of
            &nb= sp; Flow Information", July 2013.

   [RFC5102bis]
            &nb= sp; Claise, B. and B. Trammel, "Information Model for IP Flow
            &nb= sp; Information eXport (IPFIX)", February 2013.

   [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J= . Quittek,
            &nb= sp; "Architecture for IP Flow Information Export", RFC 5470,
            &nb= sp; March 2009.

Authors' Addresses

   Senthil Sivakumar
   Cisco Systems
   7100-8 Kit Creek Road
   Research Triangle Park, North Carolina 27709
   USA

   Phone: +1 919 392 5158

   Renaldo Penno
   Cisco Systems
   170 W Tasman Drive
   San Jose, California 95035
   USA

   Email: repenno@cisco.com

Sivakumar & Penno        Expires Aug= ust 15, 2014          &nb= sp;    [Page 21]

--_000_CFAA34BB106C60ssenthilciscocom_--