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

From: Dan Wing <[email-masked]>
Date: Mon, 20 May 2013 19:11:53 -0700

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.

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.

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

Similar observation as with SYSLOG on security considerations, need for clarity of the logs, and suchlike (see my SYSLOG review posted to BEHAVE).

-d

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 24 May 2013 16:49:59 +0000

On 5/20/13 10:11 PM, "Dan Wing (dwing)" <[email-masked]> 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.

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.

>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/behave

---

From: Dan Wing <[email-masked]>
Date: Fri, 24 May 2013 10:11:33 -0700

On May 24, 2013, at 9:49 AM, Senthil Sivakumar (ssenthil) <[email-masked]> wrote:

> 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

Yes, understood.

> 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