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

From: Simon Perreault <[email-masked]>
Date: Mon, 02 Dec 2013 09:17:02 -0500

Le 2013-11-30 23:37, Senthil Sivakumar (ssenthil) a écrit :
> A new version that incorporates comments from Tom and others, please
> review.
> At this time, the only outstanding issue with respect to the ipfix and
> syslog is the port block
> Allocation and deallocation schemes and parameters, for which we need some
> input from others.

What are the issues or open questions?

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

---

From: Tom Taylor <[email-masked]>
Date: Mon, 02 Dec 2013 14:03:08 -0500

> What are the issues or open questions?

In going through the updated IPFIX draft and comparing it with the MIB 
and SYSLOG draft, I note the following issues:

1. Both the IPFIX draft and the SYSLOG draft have to be updated to 
report the NAT instance number/alias.

Action: update both drafts.

2. Definition of session: taken from RFC 2663 in the IPFIX draft. The 
SYSLOG draft mistakenly says that is wrong. (Don't know how I misread that.)

Action: change the SYSLOG draft to use the same reference.

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.

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.

5. IPFIX does not support identification of the subscriber site except 
in the case of simple NAT44 or NAT64. In particular, the source IPv4 
address for DS-Lite will always be the same, regardless of which 
subscriber it comes from.

Action: add explicit site identifier parameters, in the variants 
supported by SYSLOG: IPv4 address, IPv6 address, GRE key, MPLS label, 
IPv6 Flow Label.

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

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.

7. Editorial: natPoolName appears in Table 8 but not in Table 1 of the 
IPFIX document.

Action: add to Table 1.

8. The IPFIX addresses exhausted event is pool-specific, where the MIB 
and SYSLOG events are based on a global limit on address mappings. These 
are obviously monitoring different resources (memory vs. addresses in a 
given pool). The MIB and SYSLOG monitor pool address-port utilization 
using threshold events, which IPFIX lacks.

Action: agree on a common set of events and bring all three drafts into 
line.

9. The IPFIX ports exhausted event is specific to a given global IPv4 
address. SYSLOG and the MIB have no equivalent.

Action: as for the previous item.

10. Editorial: natLimitEvent appears in Table 10 but not in Table 1 of 
the IPFIX document.

Action: add to Table 1.

11. No natEvent parameter to distinguish port allocation from port 
deallocation in IPFIX.

Action: add parameter to Table 12 template.

12. IPFIX document lacks cross-reference to corresponding MIB objects.

Action: add text giving corresponding cross-references.

13. Not sure how to interpret the IPFIX quota events: as threshold 
crossings or as hard limits. If the latter, IPFIX is missing the 
threshold events:
-- address pool port utilization (already mentioned)
-- BIB entries, global and per user

Action: I think IPFIX has to add the threshold events.

14. IPFIX does not record limit on maximum active users or maximum 
pending fragments exceeded events.

Action: I think the fragment event for sure is operationally useful and 
should be added to IPFIX. We can discuss the limit on active users, 
which came from the MIB.

15. The SYSLOG generalized quota event originally came out of my 
misunderstanding of the IPFIX quota event. I'm willing to drop it if it 
does not correspond to NAT reality.

Action: discuss need for the event, and if we conclude it is 
unnecessary, delete it from SYSLOG and the MIB.

Tom Taylor

---

From: Simon Perreault <[email-masked]>
Date: Mon, 02 Dec 2013 17:00:02 -0500

Thanks a lot for this list Tom!

Replying to the few ones that I can help move forward...

> Action: add destination realm to IPFIX.

I don't follow the implication on hairpinning. The way I read the IPFIX 
draft, only the internal realm is recorded (natOriginatingAddressRealm). 
So the problem is that the external realm is missing. Is that it?

> (except for event type and timestamp) and therefore add little value.

I don't follow this reasoning. Why would omitting information cause more 
logging events to be generated?

In addition, CGN requirements [RFC6888] contain the following:

    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.

> and SYSLOG events are based on a global limit on address mappings.

Not sure I understand. The MIB has both global and pool-specific 
notifications.

> These

Right, this has to be pool-specific and global. Nobody cares that a 
single external IP address is full.

In addition, it looks like this even only handles external *IPv4* 
addresses. Can it be made version-agnostic?

> unnecessary, delete it from SYSLOG and the MIB.

I'd be fine with dropping it from the MIB. Let me know if we have consensus.

Simon

---

From: Tom Taylor <[email-masked]>
Date: Mon, 02 Dec 2013 17:51:27 -0500

> So the problem is that the external realm is missing. Is that it?

[PTT] Agreed, the real problem is that external realm is missing. I was 
following through on one implication, but that isn't necessary.
>        be logged by the CGN.  This can help reduce the amount of logging.

[PTT] My argument is that you shouldn't log session events at all unless 
they have destination data. Otherwise you are just duplicating the BIB 
events, except that you are providing a timestamp for each new session 
the user creates. I'm not sure that little bit of additional information 
is useful for anything.
> Not sure I understand. The MIB has both global and pool-specific

[PTT] I'm talking about hard limits here. The pool-specific MIB 
notifications are threshold crossings, as I mention in the next sentence.
> addresses. Can it be made version-agnostic?

[PTT] I didn't mention that, but I was just reviewing conclusions out of 
the Berlin meeting and Dave Thaler's earlier comments and one item was 
to generalize the external address family.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 3 Dec 2013 01:51:19 +0000

Thanks for the exhaustive list, please see inline.

>Action: update both drafts.

Ok, the instance number would be an optional logging parameter.

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

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

>supported by SYSLOG: IPv4 address, IPv6 address, GRE key, MPLS label,

You mean in the IPFIX draft? I will have to re-read the syslog draft to
see 
What is done there.

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

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

>7. Editorial: natPoolName appears in Table 8 but not in Table 1 of the

Ok.
>Action: agree on a common set of events and bring all three drafts into

When would the global address exhausted event be generated by a NAT device?
The address exhausted event is triggered when a subscriber/packet requires
an address to be allocated and the subscribed/packet would be pointing to a
single pool (based on some classification mechanism), if that pool is full,
an address exhausted event is generated. There can be other pools that have
addresses in them (or not) but a nat device doesn’t check if all pools are
exhausted.

>Action: as for the previous item.

I will make the ports exhausted specific to a pool in IPFIX draft.

>10. Editorial: natLimitEvent appears in Table 10 but not in Table 1 of
Ok.

>Action: add parameter to Table 12 template.
Ok.
>Action: I think IPFIX has to add the threshold events.

Hard limits. What is the assumption in syslog draft? Is it free flowing
and you can add whichever
threshold event? I know in mib we have threshold crossings.

>unnecessary, delete it from SYSLOG and the MIB.

Ok.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 3 Dec 2013 01:54:11 +0000

>Not sure I understand. The MIB has both global and pool-specific
What is your understanding on when the global notification will be
generated from a nat device?

>single external IP address is full.
Agreed.

>addresses. Can it be made version-agnostic?

An external address is IPv6? Can you tell me what the feature we are
talking about here?
NAT66?

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 3 Dec 2013 03:42:22 +0000

Started a separate thread for this..

On 12/2/13 9:17 AM, "Simon Perreault" <[email-masked]> wrote:

>_______________________________________________
>Behave mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/behave

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 3 Dec 2013 05:15:23 +0000

>10. Editorial: natLimitEvent appears in Table 10 but not in Table 1 of

Maybe there is some confusion surrounding this. This is how I see the
natLimitEvent used.
The log would be {timestamp, natEvent=11{QuotaExceeded), natLimitEvent=1
(maxsessionentries), sourceIPv4address=10.1.1.1}

If I rename the quotaExceeded in table 2 to natLimitEvent, that should
solve your concern, right?

Thanks
Senthil

---

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

> the user creates. I'm not sure that little bit of additional information

Agreed. Either you log sessions with all their parameters, or you don't.

Thanks,
Simon

---

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
[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:48:26 -0500

Le 2013-12-02 20:51, Senthil Sivakumar (ssenthil) a écrit :
> 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?

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

> You can call that as BIB, but that is purely semantics on how you want to

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

---

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

> generated from a nat device?

    natNotifMappings NOTIFICATION-TYPE
        OBJECTS { natMappingCreations, natMappingRemovals }
        STATUS current
        DESCRIPTION
            "This notification is generated when the number of active
             mappings exceeds the value of natMappingsNotifyThreshold."
        ::= { natMIBNotifications 4 }

> An external address is IPv6? Can you tell me what the feature we are

Feature? What is this, a product design meeting? ;)

Seriously, we need to write our protocols in a version-agnostic manner 
so that they support any kind of NATxy. You don't want to have to write 
a new RFC when your product team comes up with a new NATxy feature. You 
want to be able to apply the existing RFC to any kind of NAT.

Makes sense?

Simon

---

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

...
> derived from the realm Ids?
[PTT] I assume that information comes from the realm ID. We can perhaps 
agree that if the NAT supports only one internal realm, the internal 
realm ID is optional.
> and there is only one public. Any issues with that?
[PTT] I agree, and will make it so in SYSLOG.
...
> Confusing, but I will add some text here.
[PTT] Separate E-mail sent.

...

> addresses in them (or not) but a nat device doesn’t check if all pools are
[PTT] The SYSLOG events are all driven by the MIB, so let's use the MIB 
as reference. The MIB has two categories of administratively-set limits: 
hard limits, above which packets are dropped, and thresholds, which 
trigger reporting only. Some of these are conditional on particular NAT 
behaviour.

The hard limits are on:
-- number of address mapping entries created (NOT address exhaustion as 
such)
-- global number of BIB entries created (i.e., associations between 
address mapping and port mapping)
-- subscriber-specific number of BIB entries created
-- total number of active subscribers
-- number of fragments awaiting reassembly.

The thresholds are:
-- address pool utilization, high and low water marks
-- global BIB entry high water mark
-- subscriber-specific BIB entry high water mark

SYSLOG has implemented events for all of these. I would expect the same 
of IPFIX, unless we decide that some of the limits are superfluous and 
should be dropped. The only one I myself would question is the global 
limit on number of active subscribers.

One question I have is whether your IPFIX quota events represent hard 
limits or soft limits. If the former, you need to add a couple of 
sub-event types.

In any case, what you specify in IPFIX should match what is in the MIB.

...
> threshold event? I know in mib we have threshold crossings.
[PTT] See above.
...

---

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:

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 03 Dec 2013 10:01:18 -0500

> agree that if the NAT supports only one internal realm, the internal

I disagree. See my other mail.

> [PTT] I agree, and will make it so in SYSLOG.

I disagree. See my other mail.

Simon

---

From: Tom Taylor <[email-masked]>
Date: Tue, 03 Dec 2013 10:06:54 -0500

I thought the purpose of Table 1 was to list all the parameters that 
could appear in any of the templates you define. Your example clearly 
shows natLimitEvent as such a parameter. My original remark stands.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 4 Dec 2013 03:42:28 +0000

>Feature? What is this, a product design meeting? ;)

Really, feature is a word banned in IETF? I thought it was a generic term,
did you 
Check our MIB draft on the usage of the word feature :-))

>want to be able to apply the existing RFC to any kind of NAT.

Not really. In general, I  would agree that you want write a protocol
version agnostic way,
But in this particular case, the NAT external address being an IPv6
address, I don¹t see
a use case. Designing for something that would never happen is called
over-engineering??
(Did someone say never say never? :-))

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 4 Dec 2013 03:45:31 +0000

>still be logged with IPFIX as any regular router, wouldn't it?

Not always, it depends if the logging is turned on for all the flows.

>regular flow creation event?

We need to make the log events self contained, adding dependencies to
other 
mechansims is not the best way to design the solution, IMO.

Maybe we need to ask the question of, do we need to have the intelligence
of
Originating address realm in logging.

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

The most common use case, lets take CGN, a subscriber in internal realm
Tries to access internet. Why do we have to log external realm for every
flow?

Senthil

---

From: Simon Perreault <[email-masked]>
Date: Wed, 04 Dec 2013 08:43:31 -0500

> a use case. Designing for something that would never happen is called

Well, it already exists. There are a number of NAT?6 implementations out 
there, Linux 3.7+ being one of them.

As an example, the NAT MIB has been IP version agnostic since the start 
(RFC 4008).

IMHO it's not really over-engineering because the additional complexity 
is very very low. The draft is already version-agnostic in other parts, 
so we know how to do it.

Finally, it wouldn't surprise me if IESG insisted on any new RFC being 
IP version agnostic (if not IPv6-only), in the spirit of RFC 6540...

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 04 Dec 2013 08:48:37 -0500

Le 2013-12-03 22:45, Senthil Sivakumar (ssenthil) a écrit :
> of Originating address realm in logging.

I don't know.

What I do know is that we need both the internal and external realm in 
logging.

> Tries to access internet. Why do we have to log external realm for every

Because when you read the logs you want to be able to distinguish that 
common use case from other cases where the realms differ.

Now, if you ask further "Why log realms if there is only ever one case, 
and the realms are always the same?" The answer would be: we can make 
realms optional in the protocol. But then you would need a boolean 
indicating if the realm is present. I'm not sure it would save much 
space, and it certainly would increase complexity. Easier to just always 
log the realm (could be "0" for simple NATs).

Simon

---

From: Tom Taylor <[email-masked]>
Date: Wed, 04 Dec 2013 09:03:10 -0500

> log the realm (could be "0" for simple NATs).

In the SYSLOG case, omitting a realm (because there is only one 
possibility) would save 7 bytes. But I see your complexity argument. An 
implementation is likely to use predefined templates where the values 
just have to be inserted, and any optional elements mean either multiple 
templates or additional text manipulation.

Tom