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

[Simon Perreault <[e-mail]>]

Le 2013-12-02 20:51, Senthil Sivakumar (ssenthil) a écrit :
>> 3. vlanID and ingressVRFID appear in the list of IPFIX parameters, but
>> not in the SYSLOG list. Please tell me definitively whether
>> vlanID/ingressVRFID is implied by realm identifier or supplements it.
>>
>> Action: if the other two parameters are implied by realm identifier,
>> remove them from IPFIX. If not, add them to SYSLOG.
>
> The original intent of the realm identifier is to indicate the
> private/public
> Address domains and not to overload that with the VRFID/VlanIDs.
> I can remove the vlan/vrf from IPFIX but is there a way to identify the
> originator of the traffic was in private/public realm or that is to be
> somehow derived from the realm Ids?

We need to be careful with terminology.

Realms are "internal" and "external". That's relative to the NAT 
function, not with the source of a flow that created a dynamic NAT mapping.

Only "implicit dynamic mappings" [RFC6887] are created as a result of a 
flow. Therefore the terms "originator" only applies to those mappings.

For example, if an IPFIX event is triggered by an explicit dynamic 
mapping creation (e.g., through PCP), there's no flow and there's no 
flow originator. But there's still internal and external realms, IP 
addresses, and port numbers.

We also don't use "private" or "public" since any kind of address can be 
used internally or externally.

Now, back to your question: how to determine the "originator" of the 
traffic. Based on the previous explanation, this only applies to a 
subset of the NAT mappings created.

Question: won't this originator be logged as part of regular IPFIX 
logging? I mean, a NAT creates mappings, but regular flow routing would 
still be logged with IPFIX as any regular router, wouldn't it?

If it's logged normally, then would that be sufficient?
If it's not sufficient, can we add a "pointer" from the NAT event to the 
regular flow creation event?

>> 4. By implication (since external realm is unspecified), IPFIX allows
>> only one destination realm, hence does not support hairpinning between
>> the same or different internal realms. SYSLOG and the MIB support
>> multiple destination realms.
>>
>> Action: add destination realm to IPFIX.
>
> I would like to see that the destination realm be optional, the lack of
> destination realm will mean that the traffic was originated from private
> to public
> and there is only one public. Any issues with that?

Argh! The terminology! It hurts! ;)

Yes this is a big issue. Any NAT mapping always has an external and an 
internal realm by definition. They may be the same.

This has nothing to do with the direction of a flow.

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

Again, careful with the terminology. "Session", "binding", "BIB", and 
"session table" are defined in RFC 6164.

Some NATs only have a BIB.
Some NATs only have a session table.
Some NATs have both a BIB and a session table.

Therefore:
- Sending BIB events has to be optional.
- Sending session table events has to be optional.
- A binding refers to a 3-tuple (transport protocol, internal address, 
internal port).
- A session refers to a 5-tuple (transport protocol, internal address, 
internal port, external address, external port).

I think those semantics can apply to any NAT type.

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