[MLB-WIRELESS] Re: Node x is over this way -was- Applications

[Ben Anderson]

----- Original Message -----
From: "Jon" <jon at webprophets.net.au>
To: <melbwireless at wireless.org.au>
Sent: Thursday, March 21, 2002 4:38 PM
Subject: Re: [MLB-WIRELESS] Re: Node x is over this way -was- Applications


> You're CC'ing me again.

Is this better?

>
> Ben Anderson wrote:
>
> > > >
> > > > I think it's not too hard to have a self-optimising layer that does
> > this...
> > > > At least, I haven't found a good reason as to why it's too hard...
> > > >
> > >
> > > Have a go at designing one.
> > >
> > > ;-)
> >
> > Have been, and continue to iterate the design.  Have been asking for
flaws,
> > got any new bees to throw in my bonnet to solve?
> >
>
> So you have a physical link-layer design that can:
> - allow ad-hoc entry and exit
> - self-optimise traffic routings in some sensible way
> - not reveal the locations of any nodes to any other nodes
>
> ?

Not physical layer, data-link/network (layers 2 and 3).  Should be hardware
independant.
And I don't "have" it yet, it's still in design, which is the point of this
communication :)


> > > > > Problem B - even though the nodes use physical location, GPS etc,
to
> > > > > manage link-layer optimisation, we want it to be impossible to
_prove_
> > > > > that a given node is the site of an actionable (eg. unlawful) data
> > item.
> > > >
> > > > Yup, though just that isn't enough for the safety of the node in
some
> > cases,
> > > > where guilt is assumed and you have to prove the data isn't
unlawful.
> > > >
> > >
> > > Not so fast:
> > > 1. they have to prove association
> > > 2. we don't have this situation in australia, at least not at the
moment
> >
> > Yet.  I think default encryption should be employed anyway, at least to
> > future proof it a little.  And also because it's not hard.
> >
>
> Ah! - watch out, encryption is _not_ a miracle solution.
> And Onion Routing - encrypting successive addresses within each other like
> russian dolls - is a _worst_case_ scenario.

Umm, not what I had in mind...  I was thinking just end-end encryption, ie
one encrypt, one decrypt per packet payload.  The header of the packet
should have some cryptographic signature to authenticate the authenticity of
the packet.  Relying on spoofable numbers is stupid, IMO


Cheers,
Ben.



--
To unsubscribe, send mail to minordomo at wireless.org.au with a subject of 'unsubscribe melbwireless'  
Archive at: http://www.wireless.org.au/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless