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

Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> Mon, 16 July 2012 22:19 UTC

Return-Path: <achatz@forthnetgroup.gr>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2573E11E82C6 for <behave@ietfa.amsl.com>; Mon, 16 Jul 2012 15:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbud8CEBcYQc for <behave@ietfa.amsl.com>; Mon, 16 Jul 2012 15:19:14 -0700 (PDT)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id EAC7911E826C for <behave@ietf.org>; Mon, 16 Jul 2012 15:19:13 -0700 (PDT)
Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6GMJu4d007382; Tue, 17 Jul 2012 01:19:56 +0300
Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id q6GMJubH022220; Tue, 17 Jul 2012 01:19:56 +0300
Received: from [192.168.1.2] (46.246.204.91.dsl.dyn.forthnet.gr [46.246.204.91]) (authenticated bits=0) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6GMJtv6000412; Tue, 17 Jul 2012 01:19:56 +0300
Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN)
Message-ID: <5004938A.5050306@forthnetgroup.gr>
Date: Tue, 17 Jul 2012 01:19:54 +0300
From: Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
References: <035801cd637c$34df33f0$9e9d9bd0$@com>
In-Reply-To: <035801cd637c$34df33f0$9e9d9bd0$@com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: behave@ietf.org
Subject: Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, RADIUS
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 22:19:15 -0000

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#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
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>