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

[Dan Wing <[e-mail]>]

On Jun 28, 2013, at 10:45 AM, Senthil Sivakumar (ssenthil) <[e-mail]> wrote:

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

Ok if it can be an informational reference.


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

The problem is changes, and getting those changes communicated and coordinated to the logging system and to the network devices that need to know of the changes, such as CPE (if the CPE need to know the range and steps).  This is additional operational complexity, but I don't see a way for protocols to make this work better.  When a change occurs, what happens to existing sessions that are not using the 'wrong' ports (which aren't assigned)?  This same problem exists if contiguous port range is reduced (e.g., from 1000 ports to 200 ports), but it is more complex with ports scattered across the port range.


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

Thanks.


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

Will do.

-

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