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 >
- Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNM… Dan Wing
- [BEHAVE] four data models: SYSLOG, IPFIX, SNMP, R… Dan Wing
- Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNM… Hannes Tschofenig
- Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNM… Tassos Chatzithomaoglou
- Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNM… Reinaldo Penno (repenno)
- Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNM… David Harrington
- Re: [BEHAVE] four data models: SYSLOG, IPFIX, SNM… David Harrington