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

[Tom Taylor <[e-mail]>]

This is a report on what I changed in response to your review. Thank you 
very much for your time and expertise.

On 20/05/2013 9:56 PM, Dan Wing wrote:
> 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.

[PTT] Rewrote with 2.1 talking about static, dynamic, and hybrid, and 
2.2 still talking about transition methods but with reference to 2.1. 
Dropped 2.3.

  It seems Section 2 might
> be something we would want common between the SYSLOG and IPFIX
> documents, perhaps?

[PTT] I am hoping both Section 2 and Section 3 could be common once we 
get them in shape.
>
> 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.

[PTT] Explicitly accounted for when talking about the general-purpose 
subscriber site identifier in the introductory part of Section 3.
>
> 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.
>
[PTT] Done. I expect leaving the exact contents to 
implementation/deployment (current position) will be a matter of 
discussion. Section 3 does suggest what should theoretically be reported.
>
> 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.

[PTT] This may still be an open issue. Have to review.
>
> "  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.

[PTT] Dropped destination logging from the session creation/deletion 
events. This made them identical to the BIB entry events, so I dropped 
the latter. Added a sub-section of 3.1 explaining why destination 
logging would be so rare as to not merit standardization.
>
>
> 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."

[PTT] Done.
>
> 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.

[PTT] I realized there are even more potential complications than you 
have pointed out. Evaded all of them by redefining the log as a "Port 
Allocation Change" event, with a full report of the current allocation 
at the time of reporting. Added text to allow range consolidation.
>
> 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?

[PTT] I think Senthil answered this, but the first line of defense is 
the Quota event.
>
> "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).

[PTT] For this and other error conditions, added text requiring 
implementations to provide the capability for event-specific rate limiting.
>
> 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

[PTT] Refactored the parameters to make things more understandable. 
Instead of QTyp, now have site scope (single, multiple, all) and 
protocol scope (TCP, UDP, ICMP, all).
>
>  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).

[PTT] Done. Also decided (absent input to the contrary) that no one 
would monitor logs at a universal CPE, so dropped that. Added the 
LW4over6 and MAP-E BR, hence renamed the field "Device Type" rather than 
"NAT Type".
>
> 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.

[PTT] Made PostS4 the full IPv4 address. All the Pre- addresses are 
absorbed into the general purpose SiteID.
>
> 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.

[PTT] Absorbed into SiteID, which is left to local implementation with 
the requirement that it be a human-readable string.
>
> 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.

[PTT] It already says "IETF Review", since I expect the IETF wants a 
strong say on what might be added (e.g., "66"). Is any more needed?
>
> 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.)

[PTT] Haven't dealt with this yet.
>
> -d
...