Re: [BEHAVE] short review of draft-ietf-behave-ipfix-nat-logging-00

Dan Wing <dwing@cisco.com> Fri, 24 May 2013 17:11 UTC

Return-Path: <dwing@cisco.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 B6E4321F9631 for <behave@ietfa.amsl.com>; Fri, 24 May 2013 10:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 A7SWvN4D9sgs for <behave@ietfa.amsl.com>; Fri, 24 May 2013 10:11:36 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 956E621F9615 for <behave@ietf.org>; Fri, 24 May 2013 10:11:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4340; q=dns/txt; s=iport; t=1369415494; x=1370625094; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zno41OMap+WqwLO8k9czSPz7PCuiWWses0YaXDqgtGU=; b=EOThjXQa3pjdlOWTzQe74rG+ldOx6GdpNg57ArYcKlaI+np8ALbB4tHs k1T2OLumF2efUzJd8T3+dvU1y+VQSUrpfGhN0LW6ec8zoa2F4T+pMGlA8 sI6HFTL7CFf/lmWEUq0hgZeZ5U2HrC25QXHaelZPXE2qF96qC3sZ4K2S6 Y=;
X-IronPort-AV: E=Sophos;i="4.87,736,1363132800"; d="scan'208";a="79501297"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 24 May 2013 17:11:34 +0000
Received: from [10.32.240.195] ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4OHBXen019170; Fri, 24 May 2013 17:11:33 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <CB1B483277FEC94E9B58357040EE5D0232587555@xmb-rcd-x15.cisco.com>
Date: Fri, 24 May 2013 10:11:33 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <004F5A69-001E-4138-A13C-AC37CFD8AA74@cisco.com>
References: <CB1B483277FEC94E9B58357040EE5D0232587555@xmb-rcd-x15.cisco.com>
To: Senthil Sivakumar (ssenthil) <ssenthil@cisco.com>
X-Mailer: Apple Mail (2.1503)
Cc: "<behave@ietf.org>" <behave@ietf.org>, draft-ietf-behave-ipfix-nat-logging <draft-ietf-behave-ipfix-nat-logging@tools.ietf.org>
Subject: Re: [BEHAVE] short review of draft-ietf-behave-ipfix-nat-logging-00
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: Fri, 24 May 2013 17:11:40 -0000

On May 24, 2013, at 9:49 AM, Senthil Sivakumar (ssenthil) <ssenthil@cisco.com> wrote:

> 
> 
> On 5/20/13 10:11 PM, "Dan Wing (dwing)" <dwing@cisco.com> wrote:
> 
>> This is a short review of draft-ietf-behave-ipfix-nat-logging-00.  I
>> noticed several things in this document which are similar to my review of
>> the SYSLOG document.  Please be sure to see that review and I'm sure you
>> will notice some similarities.
> Ok. Will respond back to the relevant ones in that thread.
>> 
>> I noticed draft-ietf-behave-ipfix-nat-logging-00 also seems to not
>> explain the nuances of logging the destination.  This not only could
>> increase log file size, but also impacts the memory of the NAT device and
>> forces state on otherwise-stateless devices (such as stateless NAT64,
>> MAP-E, or MAP-T, and others).  Not to mention creates a log of user
>> activity which reduces subscriber privacy.
> 
> Would add a paragraph explaining the disadvantages satisfy your concerns?
> I agree with your points on above except forcing state on the stateless
> device, which I don¹t understand how logging forces state on a stateless
> device.

A good example of the problem is a bittorrent client, which makes connections and transfers data from the same source port to hundreds of destinations.  With TCP, each different destination is clearly indicated with the SYN bit, which can trigger destination logging.  However if the client is using UDP, there is nothing handy like a SYN indicating "this is a new connection", so logging will necessarily be every packet, unless the device maintains state of which destinations it has already logged.  This is not limited to bittorrent; other applications such as Skype, webrtc, and many games also use UDP in a similar fashion.


> Also, note that the destination logging is not mandatory, and we
> can add text to make destination logging must be turned off by default.

Yes, understood.

> 
>> 
>> I see draft-ietf-behave-ipfix-nat-logging-00 also has a 'range step
>> size', but I am not aware of where 'step size' is explained or discussed
>> elsewhere.  A citation within the document to wherever 'step size' is
>> explained would be useful.
> 
> Ok.
>> 
>> It reads strangely that the Address Binding event described in Section
>> 5.4.8 shows "Mandatory: No" for both IPv4 and IPv6 source addresses --
>> surely one or the other needs to be present for this event to make sense,
>> the text says:
> 
> That should be read as either one of them is mandatory, but individually
> neither is. I don¹t know how to capture that in the table. I can add some
> text to indicate that either IPv4 or IPv6 source must be present.

If it fits, the IPv4 could say "Mandatory for IPv4 binding" and the IPv6 one could be similar, or use Notes in the table or something.

-d


> 
>>  This event will be generated when a NAT device binds a local address
>>  with a global address.  This binding event happens when the first
>>  packet of the first flow from a host in the private realm.
>> but I can't tell if, when a brand-new TCP SYN is sent by a client, if
>> that causes both an Address Binding event and _also_ a "NAT44 BIB create"
>> event, because the document does not describe a "BIB" or a "Bind entry"
>> -- if those are well-understood terms, can a citation be added, or
>> in-place definition be added?  Also would benefit from clarity around why
>> there is a Address Binding event in Section 5.4.8 versus the "BIB create"
>> events described earlier.
> 
> For the first syn, an address binding event will happen AND either an
> NAT44/NAT64 BIB event or NAT44/NAT64 session event will happen. The
> subsequent SYNs and other packets from the same internal host will not
> create an address binding event.
> 
>> 
>> Similar observation as with SYSLOG on security considerations,
>> need for clarity of the logs, and suchlike (see my SYSLOG review posted
>> to BEHAVE).
> 
> Ok, Thanks for the review.
> 
> Senthil
>> 
>> -d
>> 
>> 
>> 
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
>