Subject: Re: [BEHAVE] New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 11 Nov 2014 02:47:34 +0000

No, I am not in Honolulu. Like Tom said I can be available for a phone call.

Thanks
Senthil

From: Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 10, 2014 8:38 PM
To: Senthil Sivakumar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tom Taylor <[email-masked]<mailto:[email-masked]>>
Subject: Re: FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt

Hi, Senthil,

I'd love to talk to you about this draft (and to people about the MIB draft, and to people about the syslog draft) this week. Are you in Honolulu?

Spencer

On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Spencer,
I wanted to touch base with you to see if there are any updates on the
progress of the logging
drafts. Let us know if you are waiting on the authors on something.

Thanks
Senthil

On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)" <[email-masked]<javascript:;>>
wrote:

>A new version of the draft is published incorporating all the comments
>received. Please
>Let me know if you see anything that we discussed and agreed upon is
>missing.
>
>Thanks
>Senthil
>
>On 7/2/14 6:10 AM, "[email-masked]<javascript:;>" <[email-masked]<javascript:;>>
>wrote:
>
>>
>>A new version of I-D, draft-ietf-behave-ipfix-nat-logging-04.txt
>>has been successfully submitted by Senthil Sivakumar and posted to the
>>IETF repository.
>>
>>Name:         draft-ietf-behave-ipfix-nat-logging
>>Revision:     04
>>Title:                IPFIX Information Elements for logging NAT Events
>>Document date:        2014-07-02
>>Group:                Individual Submission
>>Pages:                24
>>URL:
>>http://www.ietf.org/internet-drafts/draft-ietf-behave-ipfix-nat-logging-0
>>4
>>.txt
>>Status:
>>https://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/
>>Htmlized:
>>http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-04
>>Diff:
>>http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-ipfix-nat-logging-04
>>
>>Abstract:
>>   Network operators expect NAT devices to log events like creation and
>>   deletion of translations and information about the resources it is
>>   managing.  The logs are essential in many cases to identify an
>>   attacker or a host that was used to launch malicious attacks and/or
>>   for various other purposes of accounting.  Since there is no standard
>>   way of logging this information, different NAT devices log the
>>   information using proprietary formats and hence it is difficult to
>>   expect a consistent behavior.  The lack of a consistent way to log
>>   the data makes it difficult to write the collector applications that
>>   would receive this data and process it to present useful information.
>>   This document describes the formats for logging of NAT events.
>>
>>
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>>
>>The IETF Secretariat
>>
>

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 11 Nov 2014 13:51:30 -0600

> No, I am not in Honolulu. Like Tom said I can be available for a phone 

That could be useful, but what I'm most curious about, is one question.

When BEHAVE concluded, the MIB/IPFIX/syslog authors were working pretty 
hard to stay in sync. When I got publication requests for these three 
drafts, I asked if there was an obvious one to process first, and got 
back that I should do the MIB draft first, rather than sending them 
through as a set and trying to keep them in sync.

Is that still the right plan? Or is the conversation Tom and Dave 
Harrington are having specific to the MIB draft, and I could start work 
on IPFIX?

Thanks,

Spencer, who is really embarrassed at how bad he was at AD-sponsored!

> To: Senthil Sivakumar <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, Tom Taylor <[email-masked] 
> <mailto:[email-masked]>>
> Subject: Re: FW: New Version Notification for 
> draft-ietf-behave-ipfix-nat-logging-04.txt
>
> Hi, Senthil,
>
> I'd love to talk to you about this draft (and to people about the MIB 
> draft, and to people about the syslog draft) this week. Are you in 
> Honolulu?
>
> Spencer
>
> On Monday, November 3, 2014, Senthil Sivakumar (ssenthil) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Spencer,
>     On 7/2/14 12:09 PM, "Senthil Sivakumar (ssenthil)"
>     <[email-masked] <javascript:;>>
>     wrote:
>
>     >On 7/2/14 6:10 AM, "[email-masked] <javascript:;>"
>     <[email-masked] <javascript:;>>
>     >wrote:
>     >
>     >>
>     >>until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>     >>
>     >>The IETF Secretariat
>     >>
>     >
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 11 Nov 2014 15:50:20 -0500

I gave that advice because I figured the MIB notifications in particular 
set the framework for some of the logs or IPFIX equivalent that had to 
be generated. Definitely some of the text and maybe content will be 
influenced by the changes now being made to the MIB. However, you could 
get a start on IPFIX.

The events driving the notifications are going to stay the same as they 
are. I've tinkered with the returned objects a bit, and that should be 
reflected in the logs. I'd better publish my conclusions.

I think our key change was to clarify what statistics we're collecting. 
At the NAT instance level these now are:

         natv2InstanceAddressMapActives              Unsigned32
           -- snapshot of number of address
              maps currently active

         natv2InstancePortMapActives                 Unsigned32
           -- snapshot of number of port
              maps currently active

         natv2InstanceTranslations                   Counter64,
           -- cumulative packets translated

         natv2InstanceAddressMapCreations            Counter64,
           -- cumulative address maps created

         natv2InstancePortMapCreations               Counter64,
           -- cumulative port maps created

         natv2InstanceAddressMapActiveLimitDrops     Counter64,
           -- cumulative packets dropped because they
              would have triggered the creation of an
              address mapping but the instance limit
              on total number of address maps has
              already been reached

         natv2InstancePortMapActiveLimitDrops        Counter64,
           -- Ditto for port mapping

         natv2InstancePendingFragmentLimitDrops      Counter64,
           -- Cumulative number of fragments dropped
              because the limit on fragments received
              out of order and awaiting reassembly has
              already been reached

         natv2InstanceSubscriberActiveLimitDrops     Counter64,
           -- cumulative number of packets dropped
              because the packet would have triggered
              the creation of a mapping and the limit
              on number of subscribers with active mappings
              has already been reached

         natv2InstanceAddressMapFailureDrops         Counter64,
           -- Cumulative number of packets dropped
              because the packet would have triggered
              the creation of a mapping, the mapping
              would have required the assignment of a
              new address, but none is available.
              I have detailed definitions of this
              and the next one to avoid overlap.

         natv2InstancePortMapFailureDrops            Counter64,
           -- Cumulative number of packets dropped
              because the packet would have triggered
              the creation of a mapping, the mapping
              would have required the assignment of a
              new port for a given protocol, but none
              is available

         natv2InstanceOtherResourceFailureDrops      Counter64,
           -- Cumulative number of packets dropped
              for some other resource-related reason.

These same statistics are collected per protocol, address pool, and 
subscriber, to the extent that they are applicable at those levels.

I did feel that Section 3 of the SYSLOG document gives a good 
description of the requirements IPFIX also has to meet.

Tom

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 12 Nov 2014 18:11:30 +0000

Sorry for the delay in responding, there is some dependency between mib and logging drafts, and as far as I can tell, we did add all the relevant events to the logging drafts.
Going forward, we want to make sure anything that we add in the MIB that is worth logging should be added to the logging draft, but that requires a case-by-case analysis.
Other than that, I don’t think it should be strictly serialized, we can let them progress along, we can hold off publishing them together just to make sure they are all consistent
With one another.

Thanks
Senthil

From: Spencer Dawkins <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 11, 2014 2:51 PM
To: Senthil Sivakumar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tom Taylor <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-ietf-behave-ipfix-nat-logging-04.txt

When BEHAVE concluded, the MIB/IPFIX/syslog authors were working pretty hard to stay in sync. When I got publication requests for these three drafts, I asked if there was an obvious one to process first, and got back that I should do the MIB draft first, rather than sending them through as a set and trying to keep them in sync.

Is that still the right plan? Or is the conversation Tom and Dave Harrington are having specific to the MIB draft, and I could start work on IPFIX?

Thanks,

Thanks
Senthil

Hi, Senthil,

Spencer

Thanks
Senthil