Subject: [OPSAWG] Logging of sessions vs. BIB entrry creation -- operators please comment

From: Tom Taylor <[email-masked]>
Date: Tue, 03 Dec 2013 09:42:12 -0500

I've isolated this one issue in hopes that we can get operator input. 
Please note the cross-posting to OPSAWG. We are talking about the 
session creation event as reported by 
draft-ietf-behave-ipfix-nat-logging-02 versus 
draft-ietf-behave-syslog-nat-logging-05. The IPFIX document makes 
destination address and port optional in that report.

Tom Taylor

On 02/12/2013 8:51 PM, Senthil Sivakumar (ssenthil) wrote:
...
>
> On 12/2/13 2:03 PM, "Tom Taylor" <[email-masked]> wrote:
>
...

>> IPFIX makes the destination data optional in the create and delete
>> session events. I've already remarked on this -- it doesn't make sense,
>> since by omitting the destination data you end up generating a whole lot
>> of events that carry the same information as the corresponding BIB event
>> (except for event type and timestamp) and therefore add little value.
>
> It was already clarified in our old exchange, as below.
>
> /START
>>
>> 7. IPFIX session event makes destination address and port information
>> optional. A session event without that information is identical to a BIB
>> event, so there is no point in reporting it. Shouldn't destination info
>> be mandatory?
>
> The destination information is not mandatory. There are nat44
> implementations
> has a session database but doesn¹t need to log the destination information.
> You can call that as BIB, but that is purely semantics on how you want to
> call that as.
> END/
>
>
>
>>
>> Action: make destination data mandatory in IPFIX session events?
>> Otherwise, provide text on relationship between the session and BIB
>> events and when type of event should be enabled vs. the other.
>
> You either generate session or BIB if destination information is optional.
> I don’t see why it causes additional events. I don’t understand why it is
> Confusing, but I will add some text here.
>
>
[PTT] My point here is not the semantics, but the frequency of logging. 
A BIB entry is created when an address mapping is associated with a port 
mapping. A session entry is created every time a new destination is 
contacted, which could be many times for the same BIB entry (virtual or 
real, depending on the implementation). Thus if you enable session 
logging you may get many times the volume of logs you would get just 
logging BIB entry creation, and these would differ only in the timestamp 
value contained in them.

Now, I can see that matching up timestamps could give you a fairly good 
traceback capability if the destination is able to provide a log of 
source address and port for the incoming packets, so maybe this is 
acceptable. It might not stand up in a court of law in cases of abuse, 
since it relies on clock synchronization between the source and 
destination. So it would be nice if an operator or two could comment on 
the issue.

...

---

From: Simon Perreault <[email-masked]>
Date: Tue, 03 Dec 2013 09:59:31 -0500

> logging BIB entry creation, and these would differ only in the timestamp

Yes, and this fact has been noted in RFC 6888:

    REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
       required to do so for administrative reasons.

    Justification:  Destination logging at the CGN creates privacy
       issues.  Furthermore, readers should be aware of logging
       recommendations for Internet-facing servers [RFC6302].  With
       compliant servers, the destination address and port do not need to
       be logged by the CGN.  This can help reduce the amount of logging.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca