Subject: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt

From: [email-masked]
Date: Wed, 08 May 2013 08:44:47 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Syslog Format for NAT Logging
	Author(s)       : Zhonghua Chen
                          Cathy Zhou
                          Tina Tsou
                          T. Taylor
	Filename        : draft-ietf-behave-syslog-nat-logging-01.txt
	Pages           : 31
	Date            : 2013-05-08

Abstract:
   With the wide deployment of Carrier Grade NAT (CGN) devices, the
   logging of NAT-related events has become very important for legal
   purposes.  The logs may be required to identify a host that was used
   to launch malicious attacks or engage in illegal behaviour, and/or
   may be required for accounting purposes.  This document identifies
   the events that need to be logged and the parameters that are
   required in the logs depending on the context in which the NAT is
   being used.  It goes on to standardize formats for reporting these
   events and parameters using SYSLOG (RFC 5424).  A companion document
   specifies formats for reporting the same events and parameters using
   IPFIX (RFC 5101).  Applicability statements are provided in this
   document and its companion to guide operators and implementors in
   their choice of which technology to use for logging.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-syslog-nat-logging-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tom Taylor <[email-masked]>
Date: Wed, 08 May 2013 11:55:43 -0400

Done at last. The updated document has two new sections:

  2. Deployment Considerations
     - discusses the logging implications of the various Softwires
       transition methods, as well some considerations arising out
       of the architectural role of the NAT.

  3. NAT-Related Events and Parameters
     - is a description at a generally coding-independent level of
       the events to be logged at NATs and their associated parameters.
       In principle the contents are the same as in the IPFIX
       document, but some reconciliation may be required.

These sections are followed by SYSLOG-specific stuff: applicability 
statement, parameter and event encoding (with lots examples of complete 
logs), and an extensive IANA section. Then the usual remaining sections.

Comments are welcome. Fire away.

Tom Taylor

>     their choice of which technology to use for logging.
...

---

From: Dan Wing <[email-masked]>
Date: Mon, 20 May 2013 18:56:41 -0700

Thanks for writing this document.

My personal review, not as chair,

Section 2.1 seems to be trying to distinguish between mechanisms that are dynamic and those that are static.  Static are DS-Lite with [I-D.tsou-behave-natx4-log-reduction] and [I-D.pcp-port-set], MAP-E, and lightweight 4over6.  Dynamic is dynamic.  Then there is the combination, which is popularly described in draft-donley-behave-deterministic-cgn.  I would suggest separate sections explaining these three things, and more concisely.  Also, Section 2.1 is titled "NAT Logging Requirements For Different Transition Methods" and has 3 paragraphs describing MAP-E, which does not do network address translation in the ISP's network; a different title for the section that discusses MAP-E seems useful.  Afterall, with MAP-E the NAT function occurs in the customer premise NAT, which is not going to generate logging messages.  It seems Section 2 might be something we would want common between the SYSLOG and IPFIX documents, perhaps?

I noticed the non-normative "Note:" regarding Gateway-Initiated DS-Lite underneath Figure 1.  Can that be moved to somewhere else so it is more normative?  (It looks like a centered <postamble>).  Perhaps it should be explained in Section 2.1, rather than here.

In Figure 1, can the user identifier be generalized a bit?  There are lots of NATs which use interface identifiers (e.g., en0, en1, en2), VLAN IDs, VRFs, to separate the inside addresses -- rather than using the fields shown here in Figure 1.  This seems to have happened in Section 3.1 (which shows VLAN ID and VRFs) but the table does not appear to allow that sort of flexibility.

Section 3.1,
  "NAT session creation and deletion events are recorded when a binding
   to a specific destination address and port is recorded in or deleted
   from the session database.  See the discussion in Section 3 of
   [RFC6146]."

That does not align with the endpoint-independent mapping described in Section 3 of RFC6146.  That is, a 'creation' event does not occur with every new destination address.

I found Section 3.1 really difficult to understand what is generated for a TCP/UDP mapping, versus what is supposed to be generated for an ICMP mapping.  

"  o  Destination IPv4 (for NAT44) or IPv6 (for NAT64) address
      (OPTIONAL);"

A NAT64 would have an IPv4 destination address.  Note this is for *destination logging*, which needs its own discussion beyond just "(OPTIONAL)" and beyond the citation that RFC6888 recommends against destination logging.   There are implementation issues with destination logging (state creation in the logging device to avoid generating a log event with every packet), and it deserves mentioning in a logging document that destination logging more than destroys the log reduction benefit of bulk port assignment.

"   o  Post-NAT destination IPv4 address (OPTIONAL);"

Seems redundant with the preceding item.

"The pre-NAT value of destination
   address will differ from the post-NAT value only in a double-NAT
   situation.  Hence in most cases even with destination logging the
   pre-NAT value will not be recorded."

I don't understand what that means.  Please make it clearer in the document.  This is the first and only time the term "double-NAT" appears in the document, which might be part of my confusion.

Section 3.4 says: "The same allocation applies to each protocol supported by the NAT." -> but you really only mean UDP and TCP, even though the NAT supports ICMP (which doesn't use ports) or even if it were to support SCTP (which does not expect NAPT devices to rewrite port numbers).  So, please say "The same ports are allocated for TCP and UDP."

Section 3.4, why are the starting and ending port numbers optional, can this work?  

Section 3.4, the Port Range Size and Range Step are too complicated.  Are 

Section 3.4 needs to explain if the same single logging event will be generated when ports are deleted, or if they are consolidated.  For example, let's say ports 100-200 are allocated to a subscriber and a logging event generated, then ports 200-250 are (later) allocated to the same subscriber and a logging event generated.  Will that second logging event indicate ports 100-250?  (I could see someone reasonably implementing that).  Would two separate deletion log events be generated, one deletion for 100-200, and another deletion for 201-250?  Or would only one log deletion event be generated?  All of these corner cases need discussion with some rules for how this is expected to work.  This could perhaps be left to implementation decision, but if that is the decision it should clearly say.

General comment for all of sections 3.5, 3.6, and 3.7:  Can a SYSLOG message be generated *before* we hit a limit?  It seems there is no highwater mark for any of those.  I expect operators would prefer knowing before hitting a limit and also when hitting a limit (because users will notice the hard failure when a limit is hit).  Thoughts?

"3.5.  NAT Address Exhaustion Event", is there expected to be anything to prevent this event from being continually generated?  Because, if the NAT is running near its limit and hits it, it will likely have a port released, then one allocated (hitting the limit again), over and over again.  Same question for Section 3.4 (port exhaustion).  And, are both events generated when the final port is allocated (seems like both would be generated).  

Section 3.7, Quota exhausted -- for the (per-user) quota a citation to REQ-11 of RFC6888 would be helpful.  I found the paragraph describing which fields are mandatory for which sort of quota difficult to understand.  I played around with a table (which did not help clarity) and some alternative wording.  But I couldn't improve the text much, because I don't really know what fields are best to send for the different sort of events.  This feels very free-form and a cause of interoperability problems with the various ways a NAT or the SYSLOG parsing code would interpret the presence of certain fields.  For example, does the lack of a subscriber-identifying address mean that a non-subscriber-specific administrative limit was hit?  It seems that is the case, which is okay, but more explicit explanation could be helpful.  Or creating separate events like was done with 3.5 and 3.6

Section 5.2.1, "NTyp: NAT Type" where it mentions NAT44 it should cite the canonical NAPT44 definition in RFC3022.  For NAT64, probably want to reference both stateful NAT64 (RFC6146) and stateless (RFC6145).  

5.2.5.  PreS4: Pre-NAT IPv4 Source Address

   PARAM-VALUE: part or all of an IPv4 address, represented in dotted
   decimal form.

Why provide only part of the IPv4 address?  For on-the-wire efficiency?  If some of the address is omitted, is it the first NNN bits that are omitted, or the last NNN bits that are omitted.  I would omit the first NNN bits if all the internal addresses shared those same NNN bits (e.g., all were 100.64/10, I could omit the first 10 bits).  I would omit the last NNN bits if assigning a /24 to a subscriber and I don't care which of their devices caused the NAT event.   

5.2.6.  PreS6: Pre-NAT IPv6 Source Address:   "PARAM-VALUE: Part or all of an IPv6 address, represented in the form specified by [
RFC5952]."

Same question -- the first part or the last part of the address?  Most subscribers are assigned a /64, so reporting the full 128 bit address is awkward, I agree.  But, similarly, most of an ISP's network will use the same IPv6 prefix so reporting the first 8 or 24 bits is redundant.  The document needs to clarify.  

And as this is string-encoded, what rules should be followed for "::", as that has changed in the last couple of years and would be good to cite.

In IANA considerations a new IANA registry is created.  This needs to additionally provide guidance for how that new registry can be extended in teh future, and a few other things. RFC5226 has details.

Security considerations:

"   When logs are being recorded for regulatory reasons, preservation of
   their integrity and authentication of their origin is essential."

The accuracy and unambiguity of the information is important, as well.  To that point, the address compression has me concerned and address compression needs more text in the document, and may deserve calling out explicitly in the security considerations section.  Also worth pointing out is the address ranges and "step range" (whatever that is) might be changed while the NAT is operating -- which impacts almost everything reported to the SYSLOG server.  Seems useful to add NAT Configuration Changed events when such things occur?

In security considerations, missing messages are not mentioned.  They should be.  Would it be worthwhile to include a sequence number (which does not appear to be part of the SYSLOG header, nor of the messages defined in this spec.)

-d

On May 8, 2013, at 8:55 AM, Tom Taylor <[email-masked]> wrote:

> These sections are followed by SYSLOG-specific stuff: applicability statement, parameter and event encoding (with lots examples of complete logs), and an extensive IANA section. Then the usual remaining sections.
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 May 2013 10:21:29 -0400

Thank you very much for the time you've spent on this. We'll study your 
comments carefully and report back on our suggested responses.

Tom Taylor

...