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

"Senthil Sivakumar (ssenthil)" <> Fri, 24 May 2013 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 114CB21F8C4C for <>; Fri, 24 May 2013 09:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7+eVsYueites for <>; Fri, 24 May 2013 09:50:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3732021F8624 for <>; Fri, 24 May 2013 09:50:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3170; q=dns/txt; s=iport; t=1369414201; x=1370623801; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6w5jFJMttehVWWchouP4DB7z8BMmHz90Hx5xqkMNKZg=; b=TguMwoSwIt5jwor1LY5ArmgHa3QEa+48RLk4ftcVxdRPA9wEU/6SvLfj 54WUIDWgHCH0U0cyTwBBDLVTu4lcyOwzXy99bTs9qtYCXtYoLj94YxwMR DD/uHIfYrcgqseqORzu/1+JtdZtTrvZ5i59jGUtoosgzCIK/ORrvph27x 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkgGAEWZn1GtJXG+/2dsb2JhbABagwgwwiqBBhZ0giMBAQEDAQEBAWsLBQ0BCCJLCyUCBA4FCId/Bgy5ewSObDEHgnNhA4hnoBSDD4Im
X-IronPort-AV: E=Sophos;i="4.87,736,1363132800"; d="scan'208";a="214680038"
Received: from ([]) by with ESMTP; 24 May 2013 16:50:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r4OGo0gu011309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 16:50:00 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Fri, 24 May 2013 11:50:00 -0500
From: "Senthil Sivakumar (ssenthil)" <>
To: "Dan Wing (dwing)" <>, draft-ietf-behave-ipfix-nat-logging <>
Thread-Topic: [BEHAVE] short review of draft-ietf-behave-ipfix-nat-logging-00
Thread-Index: AQHOVciY51mhPGSAdUOHm3rR5Afi35kUoqUA
Date: Fri, 24 May 2013 16:49:59 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>
Subject: Re: [BEHAVE] short review of draft-ietf-behave-ipfix-nat-logging-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 May 2013 16:50:06 -0000

On 5/20/13 10:11 PM, "Dan Wing (dwing)" <> 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. Also, note that the destination logging is not mandatory, and we
can add text to make destination logging must be turned off by default.

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

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

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

>Behave mailing list