[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: next step

Hi 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
I don't think that PSAMP should cover things like RPF check.  I don't think that PSAMP should define anything of that complexity.  Doing so will stifle wide-spread adoption, as at that point it comes down to deciding between supporting more/better functionality (like a higher line rate) or supporting PSAMP.  

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.
This is tricky.  I think we want to define what the PSAMP mechanisms are capable of, but not necessarily how they are implemented.  

I like Nick's original description of packet selection in his original draft document
of a filter.  Though I'm not sure if it's really enough for all applications, but I think what he specified (fleshed out appropriately of course) is reasonable to implement across a full range of platforms.


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.


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


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


and flesh out the thinner parts over the next few days.
Please send any comments on this draft charter to the list.



to unsubscribe send a message to psam p-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/>