Subject: Re: [IPFIX] NAT/FW information elements.

From: Juergen Quittek <[email-masked]>
Date: Thu, 10 May 2007 17:49:56 +0200

Dear Senthil,

Thank you for your proposal an sorry for the very late reply!

--On 17.04.07 13:38 -0700 Senthil Sivakumar (ssenthil) wrote:

> Some time back I sent a request to the list requesting some IPFIX IEs
> for NAT and FW. Some IDs are reserved for us pending discussion. I would
> like to start the discussion on this by explaining the usage of the
> fields. In the meantime, we have changed the names of the fields so that
> the terminolgy is self-explanatory. This is the new proposal:
>
> 225 	 translatedSrcAddr    nat      ipv4Address  identifier
> 226 	 translatedDstAddr    nat      ipv4Address  identifier
> 227 	 translatedSrcPort    nat      unsigned16   identifier
> 228 	 translatedDstPort    nat      unsigned16   identifier

I am not sure that your terminology is really self-explanatory.

Particularly, the term "translated" may have three different meanings:

 a) some people use it to refer to the addresses on the public side
    of the NAT where the addresses of the private side are 'translated'
    into the public address space managed by the NAT

 b) other people use it to refer to addresses the NAT has changed
    in an arriving packet (for downstream packets the destination
    is translated, for upstream packets, the source is translated)

 c) some people use it just to refer to the addresses on the 'other'
    side of the NAT with respect to the location of the observation
    domain that you are using

All three schemes have pros and cons.  We should see what terminology
is used by other IETF standards and what terminology serves our case
well.

For example, here are three that use the schema a):

  - RFC 4008 (NAT MIB) use 'privateAddrress' and 'publicAddress'
  - RFC 3989 use 'internalAddress' (private) and 'externalAddress' (public)
  - draft-ietf-midcom-mib-09.txt (MIDCOM MIB) use 'insideAddress' and 'outsideAddress'

All these would rather be in line with the earlier proposal we had:

  natOrigInsideAddr
  natTransInsideAddr
  natOrigOutsideAddr
  natTransOutsideAddr

> 229 	 origAddressRealm

How would you identify a realm? public/private?

> 230 	 natEvent             nat      unsigned16   identifier

How would you (preferably) choose the identifier?
from the NAT MIB entry?

> 231 	 fwInitiatorOctets    counter  unsigned64   quantity    octets
> 232 	 fwResponderOctets    counter  unsigned64   quantity    octets

The initiator/responder model needs to be explained clearly.
It does not apply to all NAT sessions.  Some are created by other
entities.

Also it might be confusing to use this model, if the initiator can be
on both sides of the NAT.  How would anyone know who is who?

What about 'upstreamOctets' and 'downstreamOctets'?

> 233 	 fwEvent              ???      unsigned8    identifier

I do not know what this would be.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 4342-115
NEC Europe Limited,    Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014

> 234    Unused
> 235    Unused
> 236    Unused
>
> translatedSrcAddr - The value of the source address after NAT
> translation.
> translatedDstAddr - The value of the destination address after NAT
> translation.
> translatedSrcPort - The value of the source port after NAT translation.
> translatedDstPort - The value of the destination port after NAT
> translation.
> origAddressRealm  - The realm where the packet was originate
>                     Possible values : Private(0), Public (1).
>                     See RFC 2663 for definition of address realms.
> natEvent          - Whether this is a add event (Creation of NAT
> session)
>                     or a delete event (deletion of a NAT session).
> fwInitiatorOctets - Number of octets sent by the initiator of the
> firewall session.
> fwResponderOctets - Number of octets sent by the responder of the
> firewall session.
> fwEvent           - Whether this is a add event (Creation of NAT
> session)
>                     or a delete event (deletion of a NAT session).
>
> Please let me know if there are any questions/comments.
>
> Thanks
> Senthil
>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 10 May 2007 17:49:56 +0200

Dear Senthil,

  natOrigInsideAddr
  natTransInsideAddr
  natOrigOutsideAddr
  natTransOutsideAddr

Thanks,

    Juergen

---

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Thu, 10 May 2007 09:13:59 -0700

Hi Juergen,
Thanks a lot for your comments. Please see inline. 

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Thursday, May 10, 2007 11:50 AM
> To: Senthil Sivakumar (ssenthil); [email-masked]
> Subject: Re: [IPFIX] NAT/FW information elements.
> 
> Dear Senthil,
> 
> > for NAT and FW. Some IDs are reserved for us pending discussion. I 
> > would like to start the discussion on this by explaining 
> the usage of 
> > the fields. In the meantime, we have changed the names of 
> the fields 
> > so that the terminolgy is self-explanatory. This is the new 
> proposal:
> >
The reason I came up with this terminology was that I thought the
previous terminology of inside/outside address/port that I had was
confusing and hence there were no comments. You are right the translated
terminology can be construed to be any of the above. But option c is
what I intended it to mean. In other words, the "translated" fields are
to be looked along with the "origAddressRealm" field. If the originating
address realm is Private then the translated src address is the private
domains translated source and so on. A couple of advantages with this
approach is
- the terminology is common irrespective of the packet/session
direction. 
- the packet src/dst address and packet src/dst port IEs can be reused.

> All three schemes have pros and cons.  We should see what 
> terminology is used by other IETF standards and what 
> terminology serves our case well.
> 

I thought the inside/outside terminology was confusing for some and
hence the revised proposal. But if you think that the above proposal
makes more sense and is inline with the rest of IETF docs, I would
rather adhere to the above.

> How would you identify a realm? public/private?

Yes, the session creation is triggered from public or private realm.

> How would you (preferably) choose the identifier?
I was thinking that this identifier would have the following values.
1 - Creation event. (A nat session is created.)
2 - Deletion Event. (A nat session is deleted.)

And the rest of values are unused at this time.

> It does not apply to all NAT sessions.  Some are created by 
> other entities.
> 
> Also it might be confusing to use this model, if the 
> initiator can be on both sides of the NAT.  How would anyone 
> know who is who?
> 

The above two fields are not NAT specific but rather Firewall specific.
The initiator is defined as the one who sent the first packet, (syn in
case of TCP). The responder is the one who responds to the first packet.

> I do not know what this would be.

This is an firewall equivalent of the the NAT event above. It will have
the same values as the natevent has. 

Thanks
Senthil

> Registered Office: NEC House, 1 Victoria Road, London W3 6BL, 
> UK Registered in England 2832014
> 
> 
> 
> > 234    Unused
> > 235    Unused
> > 236    Unused
> >

---

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Thu, 10 May 2007 09:13:59 -0700

Hi Juergen,

Thanks
Senthil

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 11 May 2007 01:24:49 +0200

Hi Senthil,

> - the packet src/dst address and packet src/dst port IEs can be reused.

This sounds like a mixture of a) and c).  Definitely, we need a clear
description whatever we choose.

> rather adhere to the above.

I am not yet in favor of any terminology.  The point I want to make is
that there is no self-explanatory naming, but there is a strong need
for a precise description of these Information Elements.

> And the rest of values are unused at this time.

This does not sound like an element of a flow record,
but rather like an SNMP notification.  How do you suggest
to use it?

> case of TCP). The responder is the one who responds to the first packet.

Still, how would any application receiving a flow record with these elements
know which one was the initiator?  Would the information be useful without
knowing this?

> the same values as the natevent has.

Again, how would you use it? In a flow record? In an option record?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 11 May 2007 01:24:49 +0200

Hi Senthil,

Thanks,

    Juergen

---

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Thu, 10 May 2007 18:14:05 -0700

> Sent: Thursday, May 10, 2007 7:25 PM
> Subject: RE: [IPFIX] NAT/FW information elements.
> 
> Hi Senthil,
> 
> > confusing and hence there were no comments. You are right the 
> > translated terminology can be construed to be any of the above. But 
> > option c is what I intended it to mean. In other words, the 
> > "translated" fields are to be looked along with the 
> "origAddressRealm" 
> > field. If the originating address realm is Private then the 
> translated 
> > src address is the private domains translated source and so on. A 
> > couple of advantages with this approach is
> This sounds like a mixture of a) and c).  Definitely, we need 
> a clear description whatever we choose.
> 
> terminology 
> >>   - draft-ietf-midcom-mib-09.txt (MIDCOM MIB) use 
> 'insideAddress' and 
> >> 'outsideAddress'
> >>
> I am not yet in favor of any terminology.  The point I want 
> to make is that there is no self-explanatory naming, but 
> there is a strong need for a precise description of these 
> Information Elements.
> 
> >> > 229 	 origAddressRealm
> >>
> This does not sound like an element of a flow record, but 
> rather like an SNMP notification.  How do you suggest to use it?
> 

Basically, the intention of the definition of the fields is such that
whenever a NAT session is created or deleted we would send a record.
This type of event logging is useful in large deployements that have
many NAT and Firewall sessions that are created and deleted. 

> initiator can be 
> Still, how would any application receiving a flow record with 
> these elements know which one was the initiator?  Would the 
> information be useful without knowing this?

The responder/initiator bytes will be zero when the create FW event is
sent, the delete firewall event is the one that will have the actual
bytes sent by the intiator/responder. This is not to be confused with
the traditional flow records but this is more of event logs.

> > This is an firewall equivalent of the the NAT event above. It will 
> > have the same values as the natevent has.
> 

An example is:
NAT creates a session, a record is sent to the collector as follows:

SrcAddress:10.1.1.1, TranslatedSrcAddress:100.1.1.1 Destination
Address:64.1.1.1 
Translated Destination Address:64.1.1.1 SrcPort:10040,
TranslatedSrcPort:1024,
DestinationPort:80, TranslatedDestinationPort:80, Protocol:6(TCP), NAT
Event:Create
OriginatingAddressRealm:Private.

The same information will be sent to the collector when a translation is
removed by the NAT device, with the NAT event as Delete.

Similarly for Firewall session creation and deletion.

Thanks
Senthil

> >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany 
> >> http://www.netlab.nec.de Registered Office: NEC House, 1 Victoria 
> >> Road, London W3 6BL, UK Registered in England 2832014
> >>
> >>
> >>
> >> > 234    Unused
> >> > 235    Unused
> >> > 236    Unused
> >> >

---

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Thu, 10 May 2007 18:14:05 -0700

An example is:

Thanks
Senthil

> http://www.netlab.nec.de

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 11 May 2007 09:14:52 +0200

Hi Senthil,

> many NAT and Firewall sessions that are created and deleted.

I found your example below. This sketches your idea.

> the traditional flow records but this is more of event logs.

Do you have a full description of you intended use? This looks like
a sketch of a very specific application that requires special behavior
of the metering process and exporting process and consequently
knowledge about this special behavior by an application using reported
flow records.

Basically, IPFIX was not defined for event logging.
If you want to use it like this, we should discuss the general applicability
first.  When we have a good understanding of if and how IPFIX is suited for that,
we can start discussing event logging IEs.

Can you come up with a proposal on how to use IPFIX for event logging?

> Similarly for Firewall session creation and deletion.

I see.  We should discuss the usage of IPFIX for event logging first.
Please see above.

Is this intended to become an equivalent to the midcomUnsolicitedRuleEvent
in the MIDCOM MIB (draft-ietf-midcom-mib-09.txt)?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 11 May 2007 09:14:52 +0200

Hi Senthil,

Thanks,

    Juergen

---

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Fri, 11 May 2007 05:30:59 -0700

> Sent: Friday, May 11, 2007 3:15 AM
> rather like 
> >> an SNMP notification.  How do you suggest to use it?
> >>
> >
> >> Still, how would any application receiving a flow record 
> with these 
> >> elements know which one was the initiator?  Would the 
> information be 
> Do you have a full description of you intended use? This 
> looks like a sketch of a very specific application that 
> requires special behavior of the metering process and 
> exporting process and consequently knowledge about this 
> special behavior by an application using reported flow records.
> 
> If you want to use it like this, we should discuss the 
> general applicability first.  When we have a good 
> understanding of if and how IPFIX is suited for that, we can 
> start discussing event logging IEs.
> 

Ok, I will come out with a detailed proposal and we can discuss this
further.

Thanks
Senthil
> > TranslatedSrcPort:1024, DestinationPort:80, 
> > TranslatedDestinationPort:80, Protocol:6(TCP), NAT Event:Create 
> > The same information will be sent to the collector when a 
> translation 
> > is removed by the NAT device, with the NAT event as Delete.
> >
> Is this intended to become an equivalent to the 
> midcomUnsolicitedRuleEvent in the MIDCOM MIB 
> (draft-ietf-midcom-mib-09.txt)?
> 
> Thanks,
> 
>     Juergen
> --

---

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Fri, 11 May 2007 05:30:59 -0700

Thanks
Senthil