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

From: Dan Wing <[email-masked]>
Date: Mon, 1 Jul 2013 10:11:06 -0700

On Jun 30, 2013, at 8:17 AM, Tom Taylor <[email-masked]> wrote:

> Thanks again for the time you put into this. Sorry I took so long to get
> back to you.
> 
> 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.  It seems Section 2 might
>> be something we would want common between the SYSLOG and IPFIX
>> documents, perhaps?
> 
> [PTT] I receive your suggestions with enthusiasm. I had a problem with logs that would be generated during provisioning rather than dynamically, and drew an arbitrary line that said provisioning-time logs would be out of scope of this draft. By sorting things out as you suggest, I have a neat framework for specifying the log requirements in each case. The Donley draft has a section on the topic to which we can refer.
> 
>> 
>> 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] OK, the note was really to open the question of whether we should deal with the case of GW-initiated DS-Lite. I'll take it from your comment that we should. BTW I don't see why this is a SYSLOG-specific matter, as Senthil suggested.
>> 
>> 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] Will do. Are interface identifiers, VLAN IDs and VRFs an exhaustive list or should we provide for arbitrary strings including type identification (opaque to the logging system)?

Should probably allow arbitrary strings.

-d

>> 
>> 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] I think Senthil and I have to sort out a few details in Sections 3.1 to 3.3.
> 
>> "  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.
>> 
> 
> [PTT] OK
>> 
>> "   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] I ran into this when doing the Midcom semantics. Basically the problem occurs when you map from one private space to another, or when hairpinning.
> 
> ...
> 
> [PTT] I'll respond to the rest of your remarks later.
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Tom Taylor <[email-masked]>
Date: Sun, 14 Jul 2013 22:17:22 -0400

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

[PTT] I am hoping both Section 2 and Section 3 could be common once we 
get them in shape.
> 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.
> 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.
> for a TCP/UDP mapping, versus what is supposed to be generated for an

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