Subject: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03

From: Dave Thaler <[email-masked]>
Date: Thu, 10 Nov 2011 15:30:51 +0000

1) The abstract says:
> 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.  

However the document only discusses data objects not a specific
mechanism to retrieve them.   As such, the statement above is still
true because there's no consistent way to receive such data.
So what problem is this trying to solve?   And is it useful without 
specifying what protocol to use?

2) Section 1 says:
> The usage of the term "NAT device" in this document refer to any
> NAT44, Firewall and NAT64  devices.  

The term NAT64 by itself includes both stateful NAT64 and stateless NAT64.
Why would logging be required for stateless devices?
Furthermore, the abstract talks about CGNs (where logging makes sense).
Why would the requirements in this document apply to "any" device (as
opposed to only CGNs) including CPE home gateways?   I didn't see any
text discussing or justifying this statement.
If this really is just about logging requirements for CGNs then this should
be discussed in the context of the CGN requirements document.

3) The document uses several terms without defining them:
"template", "address realm", "VRF", "NAT session", etc.   

4) Section 4 says:
> Prior to logging any events, the NAT device MUST send the template  of
> the record to the collector to declare the format of the data record
> that it is using to send the events.

The above MUST might make sense for a specific protocol, but since this
document currently doesn't require any specific protocol the MUST doesn't
make sense.   For example, if the protocol is SNMP Traps or InformRequests,
then the format is specified in a MIB and there's no
need for the NAT device to send it a MIB.   Similarly for any other protocol
the collector might have some other way of getting the template from 
somewhere other than the NAT device.

5) Section 4.1-4.3:
Some of these seem underspecified by comparison to what I'm used to
in MIBs.   (e.g., what's the format of "timestamp"?  what are the units?
since when?  Local time or UTC?)  This would be cleaner if done in some
formal way like SMIv2 or whatever, which can reference well-defined
data types.   And then no new "NAT Event Logging" registry would be 
needed from IANA either.

6) Section 4.1:
This defines "MAC address" as 48 bits which is too link-type specific.
A generic document that claims to apply to "any NAT device"
should be link-type agnostic.  (Same comment goes for "VLAN ID".)

7) Section 4.3.11:
The text confuses "user" with "source address".  They're not the same thing.
There can be many users per source address, as well as multiple source
addresses per user.

-Dave

---

From: ssenthil <[email-masked]>
Date: Thu, 10 Nov 2011 13:55:18 -0500

Thanks for the comments. Please see inline

> specifying what protocol to use?

The problem we are trying to solve is as specified above, to be able to
write applications that can collect and process them without having to deal
with vendor specific implementations. I believe trying to specify the
protocol to use to transport the data objects is beyond the scope of this
specification. We could recommend some protocol if that would make this
specification complete.

> be discussed in the context of the CGN requirements document.

Some NATs might not require it - like CPEs, but there are NATs deployed in
enterprises too (they don't have to come under the CGN umbrella) and that
would still require a logging function.

> "template", "address realm", "VRF", "NAT session", etc.

Ok, I will address them in the next revision.

> somewhere other than the NAT device.

I am not sure I see the connection between the protocol specification and
the ability to send templates. The reason for sending the template is that
the same device could be sending multiple templates (one for nat44 create
event and the other for NAT64 delete event and another for a NAT44 quota
exceeded event. All of them carry different data sets and hence the template
is necessary. 

> data types.   And then no new "NAT Event Logging" registry would be

Ok. But for NAT specific types like a translatedAddress and port those types
have to be defined.

> There can be many users per source address, as well as multiple source
If I reword this as follows, would that be better?

"The examples of Quota exceeded are to allow only certain number of NAT
sessions per device, certain number of NAT sessions per subscriber etc."

Thanks
Senthil

> -Dave
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Dave Thaler <[email-masked]>
Date: Thu, 10 Nov 2011 23:16:56 +0000

Ssenthil writes: 
> > 1) The abstract says:
> >> 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.
> >
> The problem we are trying to solve is as specified above, to be able to write
> applications that can collect and process them without having to deal with
> vendor specific implementations. I believe trying to specify the protocol to
> use to transport the data objects is beyond the scope of this specification.
> We could recommend some protocol if that would make this specification
> complete.

This draft does not currently allow you to write apps that collect and process
them without having to deal with vendor specific implementations.  To get
that, you'd have to specify what protocol to use.  Otherwise you have to
deal with vendor specific protocol code anyway so you haven't met your
stated goal.

> > If this really is just about logging requirements for CGNs then this
> > should be discussed in the context of the CGN requirements document.
> 

Ok.  Since you agree that this does not apply to "any" device, I expect you
will update the text accordingly.

[...]

> > 4) Section 4 says:
> >> Prior to logging any events, the NAT device MUST send the template
> >> of the record to the collector to declare the format of the data
> >> record that it is using to send the events.
> >
> > The above MUST might make sense for a specific protocol, but since
> > this document currently doesn't require any specific protocol the MUST
> doesn't

I understand you didn't follow what I said, so I'll try to rephrase.  A NAT
device can send all of this information to a collector without sending any 
"template" before sending the information.   Of course since you never defined
the term template, I'm assuming it means schema.   The collector might already
have the templates, and there's many examples of this today.

[...]
> sessions per device, certain number of NAT sessions per subscriber etc."

Yes that's much better.

-Dave

---

From: ssenthil <[email-masked]>
Date: Sat, 12 Nov 2011 20:35:00 -0500

> deal with vendor specific protocol code anyway so you haven't met your

There are many choices of the protocol that can be used to transport the
data. But we wanted to stay away from getting into exact recommendation of
the protocol to use.

> will update the text accordingly.

Ok I will change the text to reflect that it is not a must for all kinds of
NAT.

> have the templates, and there's many examples of this today.
I will define what a template is in the next rev. Yes, schema and template
are the same. The problem with the fixed templates is that it makes it
difficult to change and adopt to different implementations. Let me give you
an example.
If the schema/template changes the data to be exported for example an
previously optional field now becomes a part of the new template, then the
collector device need to change its template too. Having the templates sent
over dynamically provides a much greater benefit and ability to change the
schema.

Senthil

---

From: Dave Thaler <[email-masked]>
Date: Sun, 13 Nov 2011 03:45:33 +0000

> > This draft does not currently allow you to write apps that collect and
> > process them without having to deal with vendor specific
> > implementations.  To get that, you'd have to specify what protocol to
> > use.  Otherwise you have to deal with vendor specific protocol code
> > anyway so you haven't met your stated goal.
> 
> data. But we wanted to stay away from getting into exact recommendation
> of the protocol to use.

Then you should change your goal.   Personally I would be in favor of either
of two approaches:
a) be completely abstract, focus on requirements, and not protocol.
   This is what lsn-requirements draft does already.
b) be concrete, specifying a solution for a particular protocol.

Currently this draft does neither.  It's halfway in between, which is
the problem I have with it.

> >> I am not sure I see the connection between the protocol specification
> >> and the ability to send templates. The reason for sending the
> >> template is that the same device could be sending multiple templates
> >> (one for nat44 create event and the other for NAT64 delete event and
> >> another for a NAT44 quota exceeded event. All of them carry different
> >> data sets and hence the template is necessary.
> >
> > I understand you didn't follow what I said, so I'll try to rephrase.
> > A NAT device can send all of this information to a collector without
> sending any
> I will define what a template is in the next rev. Yes, schema and template are
> the same. The problem with the fixed templates is that it makes it difficult to
> change and adopt to different implementations. Let me give you an
> example.

Defining a "template" and sending it to the server is specifying part of a
protocol (and would certainly not apply to some protocols) and is one of 
the reasons this draft is not currently in category (a) as I defined it above.  
Another reason where it is not abstract (i.e. not in category a) is that it
defines bit lengths of data items.   That implies that IP addresses and ports
are sent in binary format, not in (say) string format, and hence is specifying
part of a protocol.

My recommendation would be to pick (a) or (b) and not try to be somewhere
in between, which I find confusing.

-Dave