Subject: RE: drop MPLS from the requirement (was [ipfix-req] Requirements drafts, NATed flows and VPNs)

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 9 Oct 2002 07:31:42 -0700

Hello Benoit, 

there is one exception which is L2TP, where you can have L2TP tunnel
switching, or L2TP multi-hop as some used to call. In this case the behavior
is exactly as MPLS, the difference is that L2TPv2 runs over UDP/IP. L2TPv3
runs over IP. 

Since L2TP tunnel switching is widely deployed I would say we should include
it also or drop them both...

regards,

Reinaldo

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2002 6:23 AM
> To: Penno, Reinaldo [BL60:0430:EXCH]
> Cc: Simon Leinen; req
> Subject: drop MPLS from the requirement (was [ipfix-req] Requirements
> drafts, NATed flows and VPNs)
> 
> 
> 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.
> >
> > 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.
> >
> 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
> 
> > 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.
> > >
> >
> 
> 
> 
>