[Pilz Rene <rene.pilz@xxxxxx>]

From the logical point of view it makes sense to put this functionality 
into libpcap. But in the next
step it would be necessary to change the format aswell, because it is 
too weak. Something like ERF
is already better, but still not there where I want to be.
So I ask myself if it is still a good place to put it.

ronnie sahlberg wrote:

> The place to put this functionality is to put it inside libpcap and
> winpcap. not in ethereal.
>
> This requires analysis and definition of a capture url format
> authentication and authorization.
>
>  
This is of course a very important issue. There I would ask myself if 
there is already something existing
which can be used. Can the openssl library do it for me?

> While there are prototype implementations of such a protocol in
> winpcap it can not be used in real world environments unless you find
> it acceptable that anyone in the entire world being able to capture
> from your box.
> (
> And since people will comment that it does work :   NO an mds
> fibrechannel/iscsi-gateway switch sitting on a private network in a
> large datacentre is NOT representative for how to define a security
> model.  All three mds switches in my lab work just fine with this
> protocol but i STILL consider it impossible to use in real world
> networks.
> )
>  
I don't want to have a lengthy process to develop the stuff. This means 
only that I don't want to run
into length discussions due to too many partipiants.

> Your task consists of :
> 1, analyzing the problem space for real applications,  in particular
> security, authentication and authorization.
> 2, talk to libpcap and winpcap folks to come up with a solution that
> is secure, usable and acceptable to both camps.
> (neither of the camps are particularly willing to spend much time to
> do this work for you. You have to do it)
>  
I do not expect anything. For me the situations is quiet simple. If the 
work to maintain the
code is less, when it I put it into the commuity, then I will do it. 
Otherwise I will send it
only to these once, which request it.

> 3, implement and document the solution.
>
>
> I would be willing to contribute to defining the protocol used and
> documenting it, maybe in an RFC.   Contact me off-list if you want to
> go that path, but there will be a lot of work involved.
>
>  
From my point of view, the protocol itself should be specified in every 
detail anyway. The
question there is, where you are doing a overkill and which features are 
really required.

If the outcome should be a RFC, then development process will be done in 
parallel. I need
this feature wihin the next 2-3 months. This simply means, that I have 
to hurry up anyway.

Regrads

Rene

> On Thu, 31 Mar 2005 23:36:55 +0200, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
>  
>
> > Pilz Rene <rene.pilz@xxxxxx> schrieb am 31.03.05 16:16:23:
> >    
> >
> > > Hi
> > >
> > > At the moment I am thinking to implement a capture device, which is 
> > > remotely able to trace the data. This should enable one to take a look 
> > > at the data from a capture-bot at a central office.
> > >
> > > I thought, that this should be added in the capture dialog as an 
> > > additional device, so that a person can online look which packets passes
> > >      
> > by.
> >    
> >
> > > As I already looked at the source code, I got some idea how does the 
> > > code might look like. But still I will need some time to understand the 
> > > relations beween the parts.
> > >
> > > As I have seen in the development-list you have already worked in this 
> > > area of the code. Therefore it would be nice, when you can tell me your 
> > > thoughts.
> > >
> > >      
> > Hi Rene!
> >
> > Discussions about such features should not be done privately, so I'll CC my
> > mail on to the list.
> >
> > Yes, I was doing a major redesign of the capture engine code, as this was
> > simply a mess before.
> >
> > As my main notebook is currently in repair, I won't continue this work in
> > the next days until my notebook is back.
> >
> >
> > To your question:
> >
> > Adding different capture devices were discussed on the list already before.
> >
> > Some people will argue, that features like this should be added to
> > libpcap/Winpcap, so all programs using these libs can use the feature.
> >
> > I tend to agree with them, as having a lot of different capturing devices in
> > Ethereal with different API's might not be the thing I like to see :-)
> >
> > Please note that WinPcap has already a built in remote capture feature. I
> > didn't used it, so I can't tell you how well it's going.
> >
> > Regards, ULFL
> >
> > __________________________________________________________
> > Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
> > weltweit telefonieren! http://freephone.web.de/?mc=021201
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> >    
>
>  


--
Dipl-Ing (FH) MSc. C.E Ren� Pilz
ftw. Telekommunications Research Center Vienna http://www.ftw.at
Tech Gate Vienna, Donaucitystra�e 1, A-1220 Wien
Mobile: +43 664 8269871 Office: +43 1 5052830-13  Fax: +43 1 5052830-99