Subject: [BEHAVE] Differences between SYSLOG document and NAT MIB

From: Tom Taylor <[email-masked]>
Date: Sat, 05 Oct 2013 21:47:22 -0400

To my recollection there are four open issues. The nastiest one is 
accommodating GW-initiated DS-Lite. I propose below the MIB equivalent 
to the generalized internal address solution currently provided in the 
SYSLOG document. Two other items are tables proposed in the SYSLOG 
document but not currently in the MIB. One of these is the quota table 
proposed Fri, 27 Sep 2013 12:00:27 -0400, the other a realm mapping 
table that would be defined in similar fashion. The fourth issue is a 
matter of parameter differences proposed for the MIB notifications and 
for the corresponding logs.

1. Accommodating GW-initiated DS-Lite
-------------------------------------

The problem:

Tables natMapIntAddrTable (table of address mappings), natMappingTable 
(table of BIB entries) and natSubscribersTable all rely on the 
InetAddress and InetAddressType Textual Conventions, which only allow 
for IPv4 or IPv6 addresses as identifiers of the subscriber site. 
However, Gateway-Initiated DS-Lite [RFC 6674] does not necessarily 
assign any IP address to the subscriber site, other than a private IPv4 
address which may be shared by other sites served by the same access 
gateway. To uniquely identify a subscriber site in this case, RFC 6674 
uses a context identifier (CID), which may be a GRE Key, MPLS label, 
IPv4 address, IPv6 address, or IPv6 Flow Label.

Proposed solution: define new Textual Conventions for use by the following:

- natMapIntAddrIntType and natMapIntAddrInt in natMapIntAddrTable;

- natMappingIntAddressType and natMappingIntAddress in natMappingTable;

- natSubscriberIdentifierType and natSubscriberIdentifier in 
NatSubscribersTableEntry.

The basic approach is the same as in RFC 4001. ***Note the addition of a 
prefix length object. I think this was needed in any event to cover 
sites assigned prefixes rather than just addresses.***

NatGreKeyValue ::= TEXTUAL-CONVENTION
     DISPLAY-HINT "d"
     STATUS      current
     DESCRIPTION
         "Denotes a GRE Key used as a Gateway-Initiated
          DS-Lite [RFC6674] Context Identifier."
     SYNTAX Unsigned32 (0..4294967295)

NatIPv6FlowLabel ::= TEXTUAL-CONVENTION
     DISPLAY-HINT "d"
     STATUS      current
     DESCRIPTION
         "Denotes an IPv6 Flow Label used as a
          Gateway-Initiated DS-Lite [RFC6674] Context
          Identifier."
     SYNTAX Unsigned32 (0..1048575)

NatGenIntAddressType ::= TEXTUAL-CONVENTION
     STATUS      current
     DESCRIPTION
         "A value that represents a type of generalized internal
          address or prefix assigned to a subscriber access
          device. Types  'gre(3)', 'mpls(4)', and 'flow(5)' may be
          used as context identifiers for some deployments of
          Gateway Initiated DS-Lite [RFC6674]. An object of this
          type MUST be accompanied by a corresponding address
          object and by an object of type
          NatGenIntAddressPrefixLength.

          unknown(0)  An unknown address type.  This value MUST
                      be used if the value of the corresponding
                      InetAddress object is a zero-length string.
                      It may also be used to indicate an address
                      that is not in one of the formats defined
                      below.

          ipv4(1)     An IPv4 address as defined by the
                      InetAddressIPv4 textual convention.
                      [Note import from INET-ADDRESS-MIB.]

          ipv6(2)     An IPv6 address as defined by the
                      InetAddressIPv6 textual convention,
                      modified in display to conform to
                      Sections 4 and 5 of [RFC5952].
                      [Is this legitimate? Another import.]

          gre(3)      A GRE key [RFC2890] as defined by the
                      NatGreKeyValue textual convention.

          mpls(4)     An MPLS label as defined by the MplsLabel
                      textual convention.
                      [Import from MPLS-TC-STD-MIB, RFC3811.]

          flow(5)     An IPv6 flow label as defined by the
                      NatIPv6FlowLabel textual convention."

     SYNTAX       INTEGER {
                      unknown(0),
                      ipv4(1),
                      ipv6(2),
                      gre(3),
                      mpls(4),
                      flow(5)
                  }

NatGenIntAddressPrefixLength ::= TEXTUAL-CONVENTION
     DISPLAY-HINT "d"
     STATUS       current
     DESCRIPTION
         "Denotes the length of a  generalized internal
          address or prefix assigned to a subscriber access
          device. Relevant only to types 'ipv4(1)' and 'ipv6(2)',
          but a value is specified below for use with other types.
          A value of n corresponds to an IP address mask that
          has n contiguous 1-bits from the most significant
          bit (MSB), with all other bits set to 0.

          A NatGenIntAddressPrefixLength value is always interpreted
          within the context of a NatGenIntAddressType value.  Every
          usage of the NatGenIntAddressPrefixLength textual convention
          is required to specify the NatGenIntAddressType object that
          provides the context.  It is suggested that the
          NatGenIntAddressType object be logically registered before
          the object(s) that use the NatGenIntAddressPrefixLength
          textual convention, if they appear in the same logical row.

          NatGenIntAddressPrefixLength values larger than
          the maximum length of an address for a specific
          NatGenIntAddressType are treated as the maximum significant
          value applicable for the NatGenIntAddressType.  The maximum
          significant value is 32 for the NatGenIntAddressType
          'ipv4(1)' and 128 for the NatGenIntAddressType
          'ipv6(2)'.

          The value 32 MUST be assigned to the corresponding
          NatGenIntAddressPrefixLength object for
          NatGenIntAddressType 'gre(3)', 'mpls(4)', and 'flow(5)'.
          The value 0 applies only to NatGenIntAddressType
          'unknown(0)'."
     SYNTAX       Unsigned32 (0..128)

2. Realm mapping table
----------------------

Section 2.2 of the SYSLOG document has the following text:

   "Table [proposed] in the NAT-MIB [I-D.Behave-NAT-MIB] provides a
    mapping between each realm identifier and the Virtual Routing
    Function (VRF) instance, VLAN identifier, or Gateway-Initiated DS-
    Lite softwire identifier (SWID), if any, with which it is
    associated."

I can provide a strawman proposal if you want.

3. Quota table
--------------

As noted above, we discussed this already, though without a conclusion. 
Section 3.2.9 of the SYSLOG document has the following text:

   "Table [proposed] in the
    NAT MIB lists quota identifiers and corresponding total counts of
    packets dropped because of quota violations.  This table may be
    extended to provide information on the configuration of the
    particular quota, depending on the implementation."

Strawman proposal sent 27 September.

4. Notification parameters versus SYSLOG parameters
---------------------------------------------------

The MIB notifications for address pool thresholds provide the pool 
identifier only. The SYSLOG version adds optional reporting NAT type.

The remaining MIB notifications also relate to thresholds, and 
(justifiably, to save compute time) provide the raw creation and 
deletion counter values, leaving the craftsperson to do the arithmetic 
if desired. It seemed reasonable to present the difference between the 
counters in the corresponding logs, but perhaps that was a wrong 
decision for the same reason the MIB approach is justified. Again, the 
SYSLOG version adds optional reporting NAT type for these events.

The one big discrepancy is with the subscriber-specific BIB entry 
threshold event. Here it seemed reasonable for the SYSLOG report to 
identify the subscriber site that exceeded its threshold.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Oct 2013 11:10:10 +0200

> 1. Accommodating GW-initiated DS-Lite

natMapIntAddrTable and natMappingTable contain "pure" NAT mappings. They
don't identify subscribers. They only contain internal/external
addresses/ports, which must be present for any kind of NAT by
definition. As such I don't see how those two tables could not apply to
GI-DS-Lite as-is. Please explain if I'm wrong.

natSusbscribersTable does identify subscribers:

        natSubscriberIdentifierType      InetAddressType,
        natSubscriberIdentifier          InetAddress,

I see how these two objects would need to be expanded as you propose.

> sites assigned prefixes rather than just addresses.***

Aren't assigned prefixes already covered by those three objects?

        natSubscriberIntPrefixType       InetAddressType,
        natSubscriberIntPrefix           InetAddress,
        natSubscriberIntPrefixLength     InetAddressPrefixLength,

If you're really referring to prefixes as subscriber identifier,
couldn't we simply use the network address without the prefix length?
It's just an identifier after all, we don't actually need the prefix
length to be able to distinguish different subscribers...

>                      NatIPv6FlowLabel textual convention."

Wow, lots of imports...

>     SYNTAX       Unsigned32 (0..128)

As I said above, I'm not sure we need this. In case a prefix is used,
can't we just use the base address as identifier? The only cases where
prefix length would be needed is if there are overlaps, but I don't see
this as possible.

> 2. Realm mapping table

I don't understand. Realms can be much more than this set of things. For
example, packets with a given DSCP code could be interpreted by the NAT
as being in a separate realm. Or packets with an unknown extension
header. Or packets that arrive on a Sunday. There are no limits on how a
NAT could assign mappings to realms. And all this is implemented today
on Linux's iptables or OpenBSD's pf since you can build whatever rule
you want.

What we tried to do is to created a minimal-but-still-useful definition
of realms, and not try at all to codify how a NAT knows what goes in
what realm. We try to show the current state of a NAT, now how the NAT's
algorithms have worked to arrive at that state. In particular:

- A realm is identified by an opaque string with implementation-defined
interpretation.

- Mappings have internal and external realms.

- Subscribers belong to a realm.

Why would GI-DS-Lite not work with an opaque string?

> 3. Quota table

I had almost lost that email but now I found it. I'll reply to it directly.

> 4. Notification parameters versus SYSLOG parameters

Is this necessary? Can't the admin figure out the NAT type with the pool
identifier based on the NAT's configuration?

> decision for the same reason the MIB approach is justified.

IMHO the main reasons for not having the difference in the MIB is to:

1. Avoid transitory inconsistencies with the other objects, e.g. when
walking the MIB.

2. Counters will always go up, and you can't "miss" stuff when polling.
A difference object can very quickly and you can easily miss stuff when
polling (e.g. a huge spike that does not last very long).

These reasons don't apply to syslog IMHO.

> Again, the

Are you referring to this object?

natNotifSubscriberMappings NOTIFICATION-TYPE
    OBJECTS { natSubscriberMappingCreations,
              natSubscriberMappingRemovals }
    STATUS current
    DESCRIPTION
        "This notification is generated when the number of active
         mappings exceeds the value of natSubscriberMapNotifyThresh,
         unless natSubscriberMapNotifyThresh is zero.."
    ::= { natMIBNotifications 6 }

Since natSubscriberMapping{Creations,Removals} are part of the
subscriber table, wouldn't including them in the notification also
identify the subscriber since their OID would include the subscriber
identifier, which is used as table index?

Simon

---

From: Tom Taylor <[email-masked]>
Date: Mon, 07 Oct 2013 08:14:11 -0400

I agree with most of what you say. Thanks for straightening out my 
thinking. Detailed comments below on a couple of points.

>> 1. Accommodating GW-initiated DS-Lite
...
> Wow, lots of imports...
[PTT] It was interesting to see what is defined already and what is not, 
when I did the research.

...

> Why would GI-DS-Lite not work with an opaque string?

[PTT] The only reason I proposed the table was to dispose of VLANId and 
VRFId, which are currently part of the IPFIX logs. I didn't see why they 
needed to be present given the realm. I may misunderstand on this point, 
and they may represent a finer degree of granularity than the realm and 
therefore be required. I'm happy to accept guidance on this point.

> I had almost lost that email but now I found it. I'll reply to it directly.

[PTT] The reason I proposed the quota table was just to get the 
identifiers. We can continue that discussion on the quota E-mail thread.
> identifier based on the NAT's configuration?

[PTT] Probably not necessary, don't mind omitting it.
> These reasons don't apply to syslog IMHO.

[PTT] Better reasons than I had -- I realized afterwards that the same 
device was using up compute time taking the difference that it would 
have taking the difference in the MIB. The one catch with taking 
differences is that under some transient circumstances (or if there is a 
bug) the difference can come out negative. Had that happen on the DMS 
telephone switch 30-odd years ago -- embarrassing. I guess I'll stay 
with the difference, saving the formatting and space of an additional field.
> identifier, which is used as table index?

[PTT] Ah, a MIB subtlety I missed. OK, we are equivalent, issue closed.