Subject: RE: [ipfix-req] Requirements drafts, NATed flows and VPNs

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 4 Oct 2002 18:36:52 -0700

that's fair...but the premise was the statement in the draft that IPfix
could be used for intrusion detection. Given that intrusion detection
devices get all their data from port mirroring; the limited subset of data
provided by IPfix + issues such as the lack of NAT visibility (which are
directly related to the statement) makes me wonder if we shouldn't take that
statement out.

well, somebody could always argue that IPfix can do some intrusion
detection...but I really do not think it's a good fit. The "some" argument
could be expanded to include all kinds of applications.

I could also agree we should drop the MPLS label requirement. Otherwise one
should ask why not export information about other tunneling protocols such
as L2TP/GRE/IPSEC information also. 

regards,

Reinaldo

> -----Original Message-----
> From: Simon Leinen [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 4:51 PM
> To: Penno, Reinaldo [BL60:0430:EXCH]
> Cc: req
> Subject: Re: [ipfix-req] Requirements drafts, NATed flows and VPNs
> 
> 
> [ipfix-eval-team removed from list of recipients, since this seems
>  purely a requirements issue.]
> 
> I am opposed to this proposal because it opens a can of worms if we
> start to try to accomodate arbitrary services and middleboxes.
> 
> What about those cool rate shapers that fiddle with TCP window sizes?
> If they support IPFIX, the window-fiddle-factor field ist a must!
> What about "cookie-cutting" layer 4-7 switches? The cookie field is a
> must! VoIP switches? etc. etc.
> 
> Please let's try to stick with the core goal of looking at IP (v4&v6)
> packets and the "transport" protocol or next header.
> 
> Anything else should be optional and left to other documents.  The
> IPFIX protocol just should support enough extensibility to allow this.
> 
> My counter-proposal would be to drop the MPLS label requirement from
> the requirements draft.
> -- 
> Simon.
> 
> On Mon, 30 Sep 2002 10:26:36 -0700, "Reinaldo Penno" 
> <[email-masked]> said:
> > I think there are some important packet fields/scenarios that should
> > be included in the requirements draft.
> 
> > 1 - We discussed a long time ago to include the VPN-ID as one of the
> > parameters exported. If Ipfix will be used in VPN environments for
> > accouting, QoS, monitoring, etc, this field is a must.
> 
> > 2 - There is mention to intrusion detection/security as one of the
> > applications for IPfix, but there is no requirement to export NATed
> > flows (before and after).
> 
> > In a device that supports NAT (traditional, layer 7 interception,
> > whatever) and it's going to use IPfix for security/intrusion
> > detection, dealing with NAT is must. There is no way a intrusion
> > detection device will find attacker/attacked properly without both
> > sides of a NAT flow. Not to mention accouting, billing, etc.
> 
> > I would propose to include both items on the requirements draft.
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 09 Oct 2002 15:22:38 +0200

Reinaldo, Simon,

> that's fair...but the premise was the statement in the draft that 
> IPfix could be used for intrusion detection. Given that intrusion 
> detection devices get all their data from port mirroring; the limited 
> subset of data provided by IPfix + issues such as the lack of NAT 
> visibility (which are directly related to the statement) makes me 
> wonder if we shouldn't take that statement out.
>
> detection...but I really do not think it's a good fit. The "some" 
> argument could be expanded to include all kinds of applications.
>
> I could also agree we should drop the MPLS label requirement. 
> Otherwise one should ask why not export information about other 
> tunneling protocols such as L2TP/GRE/IPSEC information also.
>
I understand your concerns about MPLS. Not really an IP flow!
However, it seems to me that there is a difference between your examples 
L2TP/GRE/IPSEC and the MPLS label requirement.
Your examples affect only the 2 end routers (for example, where the GRE 
tunnel starts and ends). While MPLS affects all the routers in the core.
So without this requirement, we would be blind in a MPLS core: not able 
to export a single flow record!

Any other tought!

Regards, Benoit

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: [email-masked]
Date: Wed, 09 Oct 2002 10:47:53 -0400

> to export a single flow record!

	Just a question. In the core all you have is the label to
	distinguish by. You might be able to get the FEC info
	but are there other attributes which can be reported?

	Paul

---

From: Benoit Claise <[email-masked]>
Date: Wed, 09 Oct 2002 17:16:04 +0200

>	but are there other attributes which can be reported?
which can be reported? Yes.
For example: underlying label(s), experimental bits, flow records about 
the underlying packets, etc...

Regards, Benoit.

---

From: [email-masked]
Date: Wed, 09 Oct 2002 12:02:36 -0400

Benoit Claise wrote:
> For example: underlying label(s), experimental bits, 

	OK.

> flow records about the underlying packets, etc...
> 
	Not sure  what you mean here can you elaborate?

	I couldn't think of any packet level attributes
	to report which is why I'm trying to get more of
	a handle on this.

	Paul

---

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Oct 2002 10:37:39 +0200

Paul,

>	to report which is why I'm trying to get more of
Let's take the example of MPLS/VPN.
You may want to report the top label FEC, the second label (VPN), the 
TOS and the Src/Dst IP of the IP packet below the labels... depending 
what you intend to do with the flow records.

Regards, Benoit.

---

From: [email-masked]
Date: Thu, 10 Oct 2002 08:15:04 -0400

> what you intend to do with the flow records.

	This is where I get confused. I thought at the transit switches
	(which I assume is what the switches in the core are) the packet 
	was switched based solely on the label. So the src/dst IP can change 
	from packet to packet.  I guess it is possible to still decode more
	of the packet but that kind of defeats the purpose of MPLS.

	Paul