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

["Senthil Sivakumar (ssenthil)" <[e-mail]>]

Sorry for the long delay in responding.. Please see inline.

On 5/20/13 9:56 PM, "Dan Wing (dwing)" <[e-mail]> 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?

Do you think those would have to be repeated or one document just refers
to the other. I prefer the later approach.

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

This is specific to syslog. So I am going to let the syslog authors
address this.

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

This is specific to syslog. So I am going to let the syslog authors
address this.

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

Agree, I will add a paragraph on the destination logging and its effects.

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

Seems specific to syslog document.

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

I guess your words are truncated here. There has been some interest on
having non-contiguous ports. It has been established that this doesn¹t
provide any added security, but it isnt as complex as you think it is to
implement. There are implementations that uses a range and step size.

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

I think it is clearly an implementation choice. But I agree, we should
have some text explaining some possible options and leave it to the
implementation.

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

Interesting thought. I have always thought that logging is more useful in
case of post mortem, to understand what happened and when. And MIB is used
as a proactive monitoring tool. We have added the threshold values in the
new mib for the address and pool exhaustion, this would serve as an
alarm/trap. 

>
>"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).  

These events should be rate limited. It shouldn¹t be generated on a
per-packet basis. In our current implementation, we generate an event when
we first hit the limit, and then either periodically, every n secs if
there are packets still getting dropped because of the lack of resources
OR when some ports were released back into the pool and exhausted again. I
am pretty sure there are other ways to implement this rate limiting but I
think adding some text around this would be helpful to the implementors. I
will do this in the ipfix document.

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

All of the above three comments are specific to Syslog, hence ignoring.

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

IPFIX registry is already in place and is being used by people to add new
fields.

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

Thanks for the review, let me know if there is anything specific to IPFIX
that I have missed to respond in this review.

Senthil

>
>-d
>
> 
>On May 8, 2013, at 8:55 AM, Tom Taylor <[e-mail]> wrote:
>
>> 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
>> 
>> On 08/05/2013 11:44 AM, [e-mail] wrote:
>>> 
>>> 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.
>>> 
>> ...
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>
>_______________________________________________
>Behave mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/behave