Re: next step

[Nick Duffield <duffield@research.att.com>]

Will,

Will Eatherton wrote:
> 
> Comments on this,
> 
> > 1.The working group should work on  some more applications where
> >  psamp can be really useful...might be as best current practices (bcp).
> >  Actually,many applications cross my mind.
> > some are as follows:
> > - source address verification:
> >  efficient packet filtering can be applied to prohibit DoS
> >  attacks by source address spoofing (RFC 2267)
> > - tracing the DoS attack path  ( like SYN attack)
> >    Packet filtering can be helpful in enhancing the security features of
> >   the routers.It not only helps in detecting the attacks but with an
> >    effective packet filtering ,certain form of attacks can be obviated .
> >
> > So,My reasoning is *best current practices on various applications
> > will give us more idea on places where psamp  will be extremely useful
> > and throw light on how well they scale with growing network and various
> > filtering and sampling techniques*.
> 
> I woulld like feedback from others if they view the intent of psamp as being
> able to cover things like source address verification (aka RPF check).  I am
> not necessarily saying its a bad idea yet (though it concerns me), but folks
> should realize the gravity of moving psamp from a "monitoring" set of goals
> to a more encompassing task of providing standardization of active features
> on router equipment (there are no RFCs on things like ACLs/rpf/etc today
> right ?).  This is quite ambitious if it really becomes a goal of psamp.
> 
> >
> > 2.I am not clear whether you are making the packet filtering
> > function to be
> > generic or leave to the discretion of the implementors.We can
> > come up with the
> > rules,matching conditions and action parameters .
> >
> > 3.The minutes does talk about counters.Packet counters do give
> > lot of details
> > and even aid in sampling.So,we should also focus on how packet
> > counters will be
> > useful in packet measurements
> >
> > 4.What i am stressing out of 2 and 3  is *the WG should also
> > address packet
> > filtering and counters  as they aid packet sampling in many ways*.
> 
> Once again without offering opinion yet, dont underestimate the complexity
> of trying to standardize the overlal mechanisms of  datapath packet
> filtering that are used as basis for wide variety of features.  I also would
> be curious what other folks had in mind as to level of specification psamp
> would provide on these sorts of functions.
> 
> Will
> 

I'm similarly wary of enlarging the scope beyond measurement. PSAMP
shouldn't work on applications, it should enable them. The model I
have is that vendors can chose to build on-board applications, such
as those Senthil describes. PSAMP's role would be to make the 
measurements and present them to those applications.

Nick

> >
> > 5.The distinction of packets by layers (MAC,IP address ,ports
> > etc..) need not be
> > made explicti.I feel  taking packet statistics at various layers
> > has its own
> > benifits.Even TCP headers have many values .Cant we  leave this
> > distinction to be
> > generic and allow to implementors discretion.Focus can  be more
> > on sampling,filtering
> > and other techniques
> >
> > 6.We should also built the framework such that integartion with
> > RMON ,Sflow and other
> > measurement framework is possible.I am more particular in this
> > because  most of the
> > implementors (ex.Foundary) apply a combination of the existing technology.
> > Also,we can reuse the existing protocols as much as we can than
> > writing from scrach.
> >
> > -senthil
> >
> > -----Original Message-----
> > From: Nick Duffield [mailto:duffield@research.att.com]
> > Sent: Wednesday, April 03, 2002 5:19 PM
> > To: psamp@ops.ietf.org
> > Cc: Bert Wijnen; Randy Bush
> > Subject: next step
> >
> >
> > Folks,
> >
> > as I understand from our area directors, the next step is for us to
> > agree upon a charter. This will be taken to the IESG, and that body
> > will decide whether to charter PSAMP as an IETF Working Group.
> >
> > This will involve reaching a consensus on the aims, scope, and
> > issues arising out of the talks and discussions at the BOF. As a
> > starting point, I'll take the draft charter from the BOF agenda
> >
> > http://www.ietf.org/ietf/02mar/psamp.txt
> >
> > and flesh out the thinner parts over the next few days.
> > Please send any comments on this draft charter to the list.
> >
> > Thanks,
> >
> > Nick
> >
> > --
> > to unsubscribe send a message to psamp-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/psamp/>
> >
> > --
> > to unsubscribe send a message to psamp-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/psamp/>
> 
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/psamp/>

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>