Subject: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jul 2012 10:55:37 -0700

As an individual, I have been worried about the possibility of disparate
data models for NATs.  We currently have four ways to report information
about a NAT or other address-sharing device,

SYSLOG, http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00
IPFIX, http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05 
SNMP, http://tools.ietf.org/html/draft-perreault-sunset4-cgn-mib
RADIUS,
http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext-03#section-
4.2

My concern is that operators may find it necessary to deploy all four
protocols (IPFIX, SYSLOG, SNMP, and RADIUS) to get their needed logging and.
This seems undesirable.  Imagine, for example, that only one of those
protocols supported pseudo-random port assignment but only one other
protocol provided alarms for when a subscriber consumed all their ports (and
thus might open a support case with the operator that "the Internet is
down").

Are my concerns misplaced?

-d

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2012 21:04:22 +0300

You of course forgot Diameter: 
http://tools.ietf.org/html/draft-ietf-dime-nat-control-17

Operators deploy different protocols for different purposes. 
The world would be great if everyone could agree to use only one protocol, like in the voice over IP world (for example)...

On Jul 16, 2012, at 8:55 PM, Dan Wing wrote:

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jul 2012 11:11:39 -0700

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, July 16, 2012 11:04 AM
> To: Dan Wing
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS
> 

That was not my question.  

My question was forcing operators to deploy multiple protocols to meet their
purposes.

-d

> The world would be great if everyone could agree to use only one
> protocol, like in the voice over IP world (for example)...
>

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Tue, 17 Jul 2012 01:19:54 +0300

Imho, every protocol is destined to cover specific needs.

For auditing reasons (which is my primary concern curtently) i would prefer to use RADIUS 
(or DIAMETER or anything AAA related), as long as the frequency of acct records remains 
within limits. Passing information to subscriber sessions could also be done through 
RADIUS push.
SYSLOG is good for fast one way communication and maybe it could be used for alerting.
SNMP (notifications) could also be used for alerting, but its usage for on-demand or 
historical detailed statistics gatherings should be preferred.
IPFIX could be used for near realtime logging and of course for statistics.

Generally i agree with your concerns, but instead of "choosing" only one protocol, i would 
prefer to have the scope of each protocol clearly/strictly defined, so depending on my 
needs i knew what to deploy.
For me, it would be an ugly joke if i had to deploy SNMP or IPFIX in order to have the 
historical correlation of username & IP-related stuff.

--
Tassos

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 16 Jul 2012 22:42:07 +0000

I see the question a bit differently.

I believe we should provide some level of standardization across these
protocols. For example, binding type representation, port ranges,  mapping
count, etc should be represented by the same data model in all protocols.
We proposed that in Taipei but at that time maybe the problem wasn't ripe.

Going on step further, in case of NAT logging we should agree on basic
information set irrespective if somebody would use Radius, IPFix or any
other protocol.

Thanks,

Reinaldo  

On 7/16/12 3:19 PM, "Tassos Chatzithomaoglou" <[email-masked]>
wrote:

>> SYSLOG, 
>>http://tools.ietf.org/html/draft-zhou-behave-syslog-nat-logging-00

---

From: David Harrington <[email-masked]>
Date: Mon, 16 Jul 2012 19:27:22 -0400

Hi,

Here is the history of IETF network management protocol standards, as far
as I have been able to determine.

Around 1988, the IETF decided (following IAB recommendations found in
RFC1052) to standardize SNMP as a stepping stone toward CMIP (and CMOT).
The SMI data modeling language and the MIB database was designed to work
with either SNMP or CMIP.
Around 1992, the effort to move toward CMIP/CMOT was assessed and
considered not worthwhile, and SNMP became "THE" IETF standard protocol
for NM, for use with the SMI and the MIB standards.
For multiple years, the argument that we should have only one standard for
NM held sway and all OPS+Mgmt support meant write an SMI MIB and use SNMP
to access the data.

Around 1994, however, operators became much more vocal about the poor fit
between SNMP and some of the tasks they needed to perform.
SNMP works well for retrieving small amounts of data using ASN.1-formatted
VarBinds, or getting asynchronous notifications.
But for other purposes, other protocols were being used that better fit
the needs of operators.
So the IETF started standardizing additional protocols requested by the
operator community (communities).
And the IETF strategy changed to "build a toolkit of standardized
protocols for managing networks".
The IRTF (NMRG) produced a document describing the difference between an
information model and data models.

RADIUS (and later Diameter) were standardized for centralized
authentication, authorization, and usage accounting.
Flow accounting protocols like RTFM, Netflow, LFAP and CRANE were merged
into an IETF standard that became IPFIX.
Syslog was in wide use by operators, but it needed security features which
demanded standardization of the protocol. The IETF produced RFC5424+.
SNMP was not good at full-device config, so netconf was developed.

RFC5706 was written to try to provide some guidance about considering
operations and management in a multi-protocol, multi-data-model
environment.

And WGs such as netconf and opsawg started producing specifications about
how to correlate and translate information between protocols and between
data models.
ISMS WG developed RADIUS support for use with SNMPv3.
Netconf developed support for carrying syslog in netconf messages.
Correlations/Translations were provided for syslog-to-snmp and
snmp-to-syslog.
Work has been done to correlate XML and YANG data modeling.
Netconf/netmod is working on translating key mibs models into yang.
And so on ...

So, yes, operators may need to develop support for multiple protocols, and
corresponding data models, for different purposes.
It is what they have requested.

Ideally, the IETF will try to standardize their ***information*** models,
so different data models for different protocols can be correlated easily.
Opsawg published a survey of IETF NM protocols and data models to help
make this easier.

WGs like behave and sunset4 and opsawg (and directorates such as MIB and
YANG and AAA Doctors) will be key to driving some consistency across
efforts.

Regarding NAT logging, I think we need to make a distinction between
device-event logging, auditing, and usage accounting.
RFC2975 did an analysis of these things and appropriate protocols.
But RFC2975 is pretty old now, and things have changed a lot since 2000.

--
David Harrington
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

---

From: David Harrington <[email-masked]>
Date: Mon, 16 Jul 2012 22:13:05 -0400

Hi,

I agree we should try to standardize a limited **information model** (see
rfc3444) for nat logging.
Then we should standardize one or more protocol-specific data models.

I do not think we should produce every variant of data model just because
we can; there should be solid justification for each standard model.
I would like to see what proprietary solutions are already being used
widely, and would benefit from standardization.

On 7/16/12 6:42 PM, "Reinaldo Penno (repenno)" <[email-masked]> wrote:

>>>http://tools.ietf.org/html/draft-cheng-behave-cgn-cfg-radius-ext-03#sect
>>>i
>>>on-
>>> 4.2
>>>