RE: next step

["Will Eatherton" <will@cisco.com>]

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

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