Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8158

 
 
 

IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events

Part 2 of 2, p. 23 to 34
Prev Section

 


prevText      Top      ToC       Page 23 
5.  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 fulfill these requirements is out of
   scope of the present document.  Some management considerations are
   covered in [NAT-LOG].  This document covers the additional
   considerations.

5.1.  Ability to Collect Events from Multiple NAT Devices

   An IPFIX Collector MUST be able to collect events from multiple NAT
   devices and decipher events based on the Observation Domain ID in the
   IPFIX header.

Top      Up      ToC       Page 24 
5.2.  Ability to Suppress Events

   The exhaustion events can be overwhelming during traffic bursts;
   hence, they SHOULD be handled by the NAT devices to rate-limit them
   before sending them to the Collectors.  For example, 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.

6.  IANA Considerations

6.1.  Information Elements

   IANA has registered the following IEs in the "IPFIX Information
   Elements" registry at [IPFIX-IANA].

6.1.1.  natInstanceID

   ElementID: 463

   Name: natInstanceID

   Description: This Information Element uniquely identifies an Instance
   of the NAT that runs on a NAT middlebox function after the packet
   passes the Observation Point. natInstanceID is defined in [RFC7659].

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC791] for the definition of the IPv4 source address
   field.  See [RFC3022] for the definition of NAT.  See [RFC3234] for
   the definition of middleboxes.

6.1.2.  internalAddressRealm

   ElementID: 464

   Name: internalAddressRealm

   Description: This Information Element represents the internal address
   realm where the packet is originated from or destined to.  By
   definition, a NAT mapping can be created from two address realms, one
   from internal and one from external.  Realms are implementation
   dependent and can represent a Virtual Routing and Forwarding (VRF)
   ID, a VLAN ID, or some unique identifier.  Realms are optional and,
   when left unspecified, would mean that the external and internal
   realms are the same.

Top      Up      ToC       Page 25 
   Abstract Data Type: octetArray

   Data Type Semantics: identifier

   Reference: See [RFC791] for the definition of the IPv4 source address
   field.  See [RFC3022] for the definition of NAT.  See [RFC3234] for
   the definition of middleboxes.

6.1.3.  externalAddressRealm

   ElementID: 465

   Name: externalAddressRealm

   Description: This Information Element represents the external address
   realm where the packet is originated from or destined to.  The
   detailed definition is in the internal address realm as specified
   above.

   Abstract Data Type: octetArray

   Data Type Semantics: identifier

   Reference: See [RFC791] for the definition of the IPv4 source address
   field.  See [RFC3022] for the definition of NAT.  See [RFC3234] for
   the definition of middleboxes.

6.1.4.  natQuotaExceededEvent

   ElementID: 466

   Name: natQuotaExceededEvent

   Description: This Information Element identifies the type of a NAT
   Quota Exceeded event.  Values for this Information Element are listed
   in the "NAT Quota Exceeded Event Type" registry, see [IPFIX-IANA].
   Initial values in the registry are defined by the table below.  New
   assignments of values will be administered by IANA and are subject to
   Expert Review [RFC8126].  Experts need to check definitions of new
   values for completeness, accuracy, and redundancy.

Top      Up      ToC       Page 26 
              +--------+---------------------------------------+
              | Value  | Quota Exceeded Event Name             |
              +--------+---------------------------------------+
              | 0      | Reserved                              |
              | 1      | Maximum session entries               |
              | 2      | Maximum BIB entries                   |
              | 3      | Maximum entries per user              |
              | 4      | Maximum active hosts or subscribers   |
              | 5      | Maximum fragments pending reassembly  |
              +--------+---------------------------------------+

                    Note: This is the same as Table 3.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC791] for the definition of the IPv4 source address
   field.  See [RFC3022] for the definition of NAT.  See [RFC3234] for
   the definition of middleboxes.

6.1.5.  natThresholdEvent

   ElementID: 467

   Name: natThresholdEvent

   Description: This Information Element identifies a type of a NAT
   Threshold event.  Values for this Information Element are listed in
   the "NAT Threshold Event Type" registry, see [IPFIX-IANA].  Initial
   values in the registry are defined by the table below.  New
   assignments of values will be administered by IANA and are subject to
   Expert Review [RFC8126].  Experts need to check definitions of new
   values for completeness, accuracy, and redundancy.


   +--------+---------------------------------------------------------+
   | Value  | Threshold Exceeded Event Name                           |
   +--------+---------------------------------------------------------+
   | 0      | Reserved                                                |
   | 1      | Address pool high threshold event                       |
   | 2      | Address pool low threshold event                        |
   | 3      | Address and port mapping high threshold event           |
   | 4      | Address and port mapping per user high threshold event  |
   | 5      | Global address mapping high threshold event             |
   +--------+---------------------------------------------------------+

                    Note: This is the same as Table 4.

Top      Up      ToC       Page 27 
   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC791] for the definition of the IPv4 source address
   field.  See [RFC3022] for the definition of NAT.  See [RFC3234] for
   the definition of middleboxes.

6.1.6.  natEvent

   The original definition of this Information Element specified only
   three values: 1, 2, and 3.  This definition has been replaced by a
   registry, to which new values can be added.  The semantics of the
   three originally defined values remain unchanged.  IANA maintains the
   "NAT Event Type (Value 230)" registry for values of this Information
   Element at [IPFIX-IANA].

   ElementID: 230

   Name: natEvent

   Description: This Information Element identifies a NAT event.  This
   IE identifies the type of a NAT event.  Examples of NAT events
   include, but are not limited to, NAT translation create, NAT
   translation delete, Threshold Reached, or Threshold Exceeded, etc.
   Values for this Information Element are listed in the "NAT Event
   Type" registry, see [IPFIX-IANA].  The NAT event values in the
   registry are defined by Table 2 in Section 4.3.  New assignments of
   values will be administered by IANA and are subject to Expert Review
   [RFC8126].  Experts need to check definitions of new values for
   completeness, accuracy, and redundancy.

   Abstract Data Type: unsigned8

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.  See RFC 8158 for the definitions
   of values 4-16.

6.1.7.  maxSessionEntries

   ElementID: 471

   Name: maxSessionEntries

   Description: This element represents the maximum session entries that
   can be created by the NAT device.

Top      Up      ToC       Page 28 
   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.8.  maxBIBEntries

   ElementID: 472

   Name: maxBIBEntries

   Description: This element represents the maximum BIB entries that can
   be created by the NAT device.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.9.  maxEntriesPerUser

   ElementID: 473

   Name: maxEntriesPerUser

   Description: This element represents the maximum NAT entries that can
   be created per user by the NAT device.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.10.  maxSubscribers

   ElementID: 474

   Name: maxSubscribers

   Description: This element represents the maximum subscribers or
   maximum hosts that are allowed by the NAT device.

Top      Up      ToC       Page 29 
   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.11.  maxFragmentsPendingReassembly

   ElementID: 475

   Name: maxFragmentsPendingReassembly

   Description: This element represents the maximum fragments that the
   NAT device can store for reassembling the packet.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.12.  addressPoolHighThreshold

   ElementID: 476

   Name: addressPoolHighThreshold

   Description: This element represents the high threshold value of the
   number of public IP addresses in the address pool.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.13.  addressPoolLowThreshold

   ElementID: 477

   Name: addressPoolLowThreshold

   Description: This element represents the low threshold value of the
   number of public IP addresses in the address pool.

Top      Up      ToC       Page 30 
   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.14.  addressPortMappingHighThreshold

   ElementID: 478

   Name: addressPortMappingHighThreshold

   Description: This element represents the high threshold value of the
   number of address and port mappings.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.15.  addressPortMappingLowThreshold

   ElementID: 479

   Name: addressPortMappingLowThreshold

   Description: This element represents the low threshold value of the
   number of address and port mappings.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.16.  addressPortMappingPerUserHighThreshold

   ElementID: 480

   Name: addressPortMappingPerUserHighThreshold

   Description: This element represents the high threshold value of the
   number of address and port mappings that a single user is allowed to
   create on a NAT device.

Top      Up      ToC       Page 31 
   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.

6.1.17.  globalAddressMappingHighThreshold

   ElementID: 481

   Name: globalAddressMappingHighThreshold

   Description: This element represents the high threshold value of the
   number of address and port mappings that a single user is allowed to
   create on a NAT device in a paired address pooling behavior.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference: See [RFC3022] for the definition of NAT.  See [RFC3234]
   for the definition of middleboxes.  See [RFC4787] for the definition
   of paired address pooling behavior.

7.  Security Considerations

   The security considerations listed in detail for IPFIX in [RFC7011]
   apply to this document as well.  As described in [RFC7011], the
   messages exchanged between the NAT device and the Collector MUST be
   protected to provide confidentiality, integrity, and authenticity.
   Without those characteristics, the messages are subject to various
   kinds of attacks.  These attacks are described in great detail in
   [RFC7011].

   This document re-emphasizes the use of Transport Layer Security (TLS)
   or Datagram Transport Layer Security (DTLS) for exchanging the log
   messages between the NAT device and the Collector.  The log events
   sent in cleartext can result in confidential data being exposed to
   attackers, who could then spoof log events based on the information
   in cleartext messages.  Hence, the log events SHOULD NOT be sent in
   cleartext.

   The logging of NAT events can result in privacy concerns as a result
   of exporting information such as the source address and port
   information.  The logging of destination information can also cause
   privacy concerns, but it has been well documented in [RFC6888].  A
   NAT device can choose to operate in various logging modes if it wants

Top      Up      ToC       Page 32 
   to avoid logging of private information.  The Collector that receives
   the information can also choose to mask the private information but
   generate reports based on abstract data.  It is outside the scope of
   this document to address the implementation of logging modes for
   privacy considerations.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4787]  Audet, F., Ed. and C. Jennings, "Network Address
              Translation (NAT) Behavioral Requirements for Unicast
              UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
              2007, <https://www.rfc-editor.org/info/rfc4787>.

   [RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, DOI 10.17487/RFC5382, October 2008,
              <https://www.rfc-editor.org/info/rfc5382>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <https://www.rfc-editor.org/info/rfc6146>.

   [RFC6302]  Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
              "Logging Recommendations for Internet-Facing Servers",
              BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011,
              <https://www.rfc-editor.org/info/rfc6302>.

   [RFC6888]  Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
              A., and H. Ashida, "Common Requirements for Carrier-Grade
              NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
              April 2013, <https://www.rfc-editor.org/info/rfc6888>.

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/info/rfc7011>.

Top      Up      ToC       Page 33 
   [RFC7659]  Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor,
              "Definitions of Managed Objects for Network Address
              Translators (NATs)", RFC 7659, DOI 10.17487/RFC7659,
              October 2015, <https://www.rfc-editor.org/info/rfc7659>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [IPFIX-IANA]
              IANA, "IPFIX Information Elements",
              <http://www.iana.org/assignments/ipfix>.

   [NAT-LOG]  Chen, Z., Zhou, C., Tsou, T., and T. Taylor, Ed., "Syslog
              Format for NAT Logging", Work in Progress, draft-ietf-
              behave-syslog-nat-logging-06, January 2014.

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, DOI 10.17487/RFC2663, August 1999,
              <https://www.rfc-editor.org/info/rfc2663>.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              DOI 10.17487/RFC3022, January 2001,
              <https://www.rfc-editor.org/info/rfc3022>.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
              <https://www.rfc-editor.org/info/rfc3234>.

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424,
              DOI 10.17487/RFC5424, March 2009,
              <https://www.rfc-editor.org/info/rfc5424>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

Top      Up      ToC       Page 34 
Acknowledgements

   Thanks to Dan Wing, Selvi Shanmugam, Mohamed Boucadir, Jacni Qin,
   Ramji Vaithianathan, Simon Perreault, Jean-Francois Tremblay, Paul
   Aitken, Julia Renouard, Spencer Dawkins, and Brian Trammell for their
   review and comments.

Authors' Addresses

   Senthil Sivakumar
   Cisco Systems
   7100-8 Kit Creek Road
   Research Triangle Park, NC  27709
   United States of America

   Phone: +1 919 392 5158
   Email: ssenthil@cisco.com


   Reinaldo Penno
   Cisco Systems
   170 W Tasman Drive
   San Jose, CA  95035
   United States of America

   Email: repenno@cisco.com