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

Dave Thaler <dthaler@microsoft.com> Thu, 10 November 2011 23:16 UTC

Return-Path: <dthaler@microsoft.com>
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 749FA21F8AF4 for <behave@ietfa.amsl.com>; Thu, 10 Nov 2011 15:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.605
X-Spam-Level:
X-Spam-Status: No, score=-110.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 xKT++8jbDypp for <behave@ietfa.amsl.com>; Thu, 10 Nov 2011 15:16:58 -0800 (PST)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0821F87D9 for <behave@ietf.org>; Thu, 10 Nov 2011 15:16:58 -0800 (PST)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Nov 2011 15:16:58 -0800
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 10 Nov 2011 15:16:58 -0800
Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.162]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0355.003; Thu, 10 Nov 2011 15:16:58 -0800
From: Dave Thaler <dthaler@microsoft.com>
To: ssenthil <ssenthil@cisco.com>, "behave@ietf.org" <behave@ietf.org>
Thread-Topic: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03
Thread-Index: AcyfW5BCln8kX3wLSUicEd9FWWl3jQAfrm8OAAjyqmA=
Date: Thu, 10 Nov 2011 23:16:56 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B2EBF5A@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
References: <9B57C850BB53634CACEC56EF4853FF653B2E9B35@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <CAE18846.1B480%ssenthil@cisco.com>
In-Reply-To: <CAE18846.1B480%ssenthil@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03
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: Thu, 10 Nov 2011 23:16:59 -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.
> >
> > 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?
> 
> 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.

> > 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.
> 
> 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.

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
> > 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.
> 
> 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 
"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.

[...]
> > 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.
> >
> 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."

Yes that's much better.

-Dave