IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events
draft-ietf-behave-ipfix-nat-logging-13

I am agreeing with Mirja that tables shouldn't be duplicated.

Thanks for addressing my discuss about fully defining low threshold.

= General =

(1) I agree with Ben's comments. In particular, while the citation to RFC 7011 in Section 10 is helpful, there are new privacy threats introduced by this specification based on the information it exposes which are not documented in RFC 7011.

(2) Was it not possible to find someone from the community to shepherd this document?

= Section 5.1 =

"Logging of
   destination information also results in the loss of privacy and hence
   should be done with caution."

This is true not only for destination information but for source address information, and ports and timestamps when combined with address information. It's fine to advise caution, but it would be better if this didn't sound like destination information is the only privacy-impacting exposure.

Substantive Comments:

- General: I think this document would benefit from a privacy considerations section. In particular, has any thought been given to log minimization? For example, source addresses are mostly marked as mandatory--is there no use case for logs without them? (I considered making this a DISCUSS, but I recognize that NAT logging needs certain elements to be minimally useful, and maybe source addresses fall into that category.)

- 2, first paragraph, third sentence: Please consider saving the MUST for the detailed procedures, or at least avoid stating it in passing as part of a definition.

-3, first paragraph, last sentence: This is an odd usage of a 2119 SHOULD NOT. Is the point to say that, whatever the transport choice, some reliability mechanism SHOULD be used?

-4 , third paragraph: "An appropriate throttling mechanism
   shall be used to handle the oversubscription"
Is that "shall" intended as normative?

-5, last paragraph: Accounting use cases often have stringent reliability and timing requirements that go beyond simply saying "SHOULD NOT lose records." Does this document consider those requirements? Or more to the point, does the working group consider this appropriate for accounting applications? (As opposed to something like RADIUS or Diameter.)

- section 5.2, "Some of the IPFIX IEs are not assigned yet, and
hence the detailed description of these fields are requested in the
IANA considerations section.":

I don't understand the intent. This section should (and does) include the descriptions. Did you mean to say that the IPFIX ID numbers (marked TBD in a few cases) are requested in the IANA consideration section?

Editorial Comments and Nits:

- IDNits complains about several references, including a normative downref to RFC2663 that does not appear to be in either the downref registry of the LC announcement.

- 2: It seems a bit odd to get all the way to section 2 before seeing a basic intro of what the doc is about. It's up to you, but please consider merging section 1 into section 2.1, and decrementing the section numbers accordingly.

- section 5, general: There are a lot of 2119 keywords in this section that seem to generically apply to IPFIX. Are these new requirements specific to NAT logging? If not, please consider replacing the 2119 keywords with descriptive language.

- 11.2: Given that the security considerations are almost completely delegated to RFC7011, the reference should probably be normative.

Thank you for solving the DISCUSS and COMMENT points.

Paul's review comments:

Document: draft-ietf-behave-ipfix-nat-logging-11
Reviewer: Paul Kyzivat
Review Date:
IETF LC End Date: 2016-02-12
IESG Telechat date: 2016-12-01

Summary:

This draft is on the right track but has open issues, described in the review.

Major: 0
Minor: 5
Nits:  1

(1) Minor:

A sentence in Section 3 says: "This document focuses exclusively on the specification of IPFIX IEs." But this statement appears to be false. A large part of the document (Section 5.6) specifies Templates. It appears to be an important aspect of the document that goes beyond specifying just IEs. So the statement should be expanded.

(2) Minor:

Section 5.2 starts with "The templates could contain a subset of the Information Elements(IEs) shown in Table 1 depending upon the event being logged."

This is not a normative statement. It isn't clear what is normative regarding the use and content of templates. If I understand RFC7011, a NAT device can use any number of templates, and those templates can reference any defined IE. Is *this* document intended to *restrict* the form and number of templates used for logging NAT devices? Or is it simply suggesting some templates that may be modified as desired to fit the needs of a particular NAT device device?

These templates do not have any Information Element that uniquely identifies to the IPFIX collector that this template is being used. So how does the collector know that the particular event is intended to follow the definitions in this draft, rather than simply some proprietary template? Absent that, how do normative statements of what must be in the template mean anything?

(3) Minor:

Section 5.6 says: "Depending on the implementation and configuration various IEs specified can be included or ignored."

What is the normative intent of this statement? Is it defining what is meant by the "Mandatory" field in the tables? (I.e., that in the templates it sends the NAT device MUST include fields with Mandatory=Yes but MAY omit fields with Mandatory=No.) This should be revised to make the normative behavior clearer.

(4) Minor:

Within the IANA Considerations, section 8.1 deals with Information Elements, with one subsection for each new IE being defined. Some of these (8.1.4 natQuotaExceededEvent, 8.1.5 netThresholdEvent, 8.1.6 netEvent) each require a new IANA subregistry to be defined. They do this rather informally within the body of the corresponding subsection. Perhaps IANA will figure this out, but there is opportunity for misunderstanding. It would be better if there were separate subsection of section 8 for each of these registry creation actions. E.g. 8.2 NAT Quota Exceeded Event Type, 8.3 NAT Threshhold Event Type, 8.4 NAT Event Type.

(5) Minor:

Section 9 appears to be normative, since it uses 2119 language. But it appears at a position in the document (after Acknowledgements and IANA Considerations, before Security Considerations), where I would normally not expect to find normative language.

Perhaps this is intended to be more of an appendix. If so, then the normative language should be removed, and it ought to be formatted as an appendix.

If it is intended to be normative, then I suggest that it be moved ahead of the Acknowledgements.

(6) Nit:

Running IDNits returns a number of issues, mostly regarding references.

Thanks for your work on this draft.  Logging is going to be increasingly more important.

In section 4, I think it could be important to note the use of logs for debugging.  As sessions are increasingly encrypted, debugging will rely on information in other places.  

In regard to the privacy concerns associate with logs raised by Ben & Alissa, since this is tied to syslog, I would rather see the configurable levels allow for the privacy options needed.  On one hand, organizations may need the ability to debug issues, but on normal operations, a lower level of logging to protect privacy should be the recommendation.    Some organizations will need the ability to increase logging levels and this might be completely within reason if it is contained to their organization's network.

One high level comments:
Why are there subevent for natQuotaExceededEvent and natThresholdEvent? I don't see any reason why not to simply have them as natEvents (and part of table 2).

Minor comments:

1) section 5 says:
"The list of 
   collectors and its associated information like the transport address,
   port and protocol MUST be preserved across reboots."
 - I don't think this should be an upper-letter MUST because there could be other mechanisms to retain this list. I would go for lower case or SHOULD.
- What's an transport address? Do you mean IP address?

2) No need to have table 3 (22) an 4 (23) twice; just refer to it as done in section 8.1.6.

Thanks for handling my discuss points.

I still don't buy the argument for the exception to the SHOULD NOT for 
use of TLS - that is, I don't really get why you couldn't have made that
a MUST-use-TLS-always statement.

Thanks for addressing my DISCUSS and COMMENT points.