[BEHAVE] Major NAT MIB Issue: Notifications and processor requirements at the agent

[Tom Taylor <[e-mail]>]

A little terminology to start with:

1) A realm defines an addressing space. Simple NATs may support just two 
realms: internal and external. This is all that RFC 4008 supports. In 
more complex situations the NAT will support several or many realms. 
Individual realms in that case can be internal from the point of view of 
some hosts served by the NAT and external from the point of view of others.

2) An address mapping is an assignment of an address in a selected 
external realm to the address of a host in its internal realm.

3) An address and port mapping is a mapping between the address and port 
of a host in its internal realm for a given protocol to an address and 
port in a selected external realm. For mappings triggered by packets 
outgoing from the internal host, the external realm is selected based on 
the packet destination. For mappings triggered by packets incoming from 
an external realm, the external realm is the one from which the packet 
originated.

4) An address pool is a separately-managed set of addresses and 
ports/ICMP identifiers in a particular realm, available for assignment 
to the 'external' portion of a mapping. Pools can be used to ration the 
available external addresses to different realms and classes of 
subscribers. Where more than one pool has been assigned to the realm, 
policy determines which subscribers and/or services are mapped to which 
pool.


The NAT MIB (draft-ietf-behave-nat-mib-11) currently has five 
notifications, which can be enabled and disabled through their 
respective threshold settings:

- Address pool low threshold undershot
   -- reports under-utilization of an address pool

- Address pool high threshold exceeded
   -- reports potential over-utilization of an address pool

- Address mapping threshold exceeded
   -- reports potential exhaustion of addresses
      for the NAT instance as a whole

- Address and port mapping threshold exceeded
   -- reports potential exhaustion of address plus port
      combinations for the NAT instance as a whole

- Per-subscriber address and port mapping threshold exceeded
   -- can be used for troubleshooting (enabled for specific
      subscriber) or provisioning (enabled for all subscribers)

Just as a preliminary, my personal view is that the notification 
relating to low pool utilization should not be there, and if the 
information is needed, it should be handled by the management 
application. Hence this one should be omitted from the discussion which 
follows.

David Harrington in his review was concerned that these notifications 
involved calculations at the agent that were excessively demanding of 
processor capacity. This is especially true of the MIB's current 
algorithm for address pool utilization. More on that in a moment.

Just for background, the MIB supports the following read-write hard 
limits, beyond which incoming packets are dropped rather than translated:

- Maximum number of active address mappings
- Maximum number of active address and port mappings
- Maximum number of fragments awaiting reassembly
- Maximum number of subscribers with active address and port mappings

The resources that need monitoring in the NAT are NAT memory, address 
pool utilization, and processor capacity. The only item in the above 
list of notifications and limits that at least partially addresses 
processor capacity is the last limit, on number of active subscribers. 
Possibly, a notification and limit could be introduced based on the rate 
of change of the number of active mappings.

The problem with NAT pool monitoring is that the pool actually contains 
two resources, addresses and ports, and how they get used up depends on 
RFC 4787 pooling behaviour.

For the RECOMMENDED pooling behaviour of 'paired', port exhaustion 
occurs when all the ports for the desired protocol available to the 
subscriber on a mapped external address are used up, the NAT cannot (for 
reasons of policy or availability) assign additional ports to that 
subscriber on that same address, and the NAT cannot assign an additional 
address containing free ports to that subscriber. (This last condition 
is subject to discussion: is it port exhaustion or address exhaustion?)

For a pooling behaviour of 'arbitrary', port exhaustion occurs when 
there is no available port for the desired protocol at any of the 
addresses in the pool. Clearly port exhaustion will be a rarer event in 
the 'arbitrary' case.

draft-ietf-behave-nat-mib-11 triggers notifications based on the ratio 
of active address and port mappings using a given pool to the total 
number of address-port combinations made available by the pool, 
expressed as a percentage. As David Harrington pointed out, this makes a 
lot of demands on the agent processor. We have some alternatives:

1) No notification: leave any processing to the management application.

2) Trigger the high usage notification based on the rate of occurrence 
of out-of-port events, with the same threshold value for all pools. This 
is reasonably valid statistically for a low threshold (i.e., taking the 
view that any port exhaustion at all is actionable), but not terribly 
reliable in the 'paired' case, in that a single subscriber can dominate 
the results.

3) Trigger the high usage notification based on the rate of occurrence 
of out-of-port events, with a higher threshold value based on pool size 
(addresses x ports) and sharing ratio. This requires some mathematical 
analysis and per-pool configuration.

What do people recommend?

Tom Taylor