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 protected]> 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.
...
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
