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

[David Harrington <[e-mail]>]

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)
[e-mail]
[phone]





On 7/16/12 6:19 PM, "Tassos Chatzithomaoglou" <[e-mail]>
wrote:

>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
>
>Dan Wing wrote on 16/7/2012 20:55:
>> 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#secti
>>on-
>> 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
>>
>>
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>>
>
>
>_______________________________________________
>Behave mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/behave