RE: Sliding/Shifting/Morphing firewalls

["Stout, Bill" <StoutB () pioneer-standard com>]

Someone told me it's been done already.  Damn, can't retire yet. ;)

One application would be for high-bandwidth site-to-site WAN networking
across the Internet with a low possibility of D.O.S. vulnerability.  A
RAIDset of Firewalls or RAIFset just might do the trick.  RAIF being modeled
on the technologies of SSHF radio and disk RAIDsets (prior art), and would
be done over parallel and redundant paths over public, public/private, or
private links, using IP/IPsec.  (I can hear my patent attorney choking
himself now...). ;)

[Thinking aloud]
'Course the RAIFset would have to be coded with a daily key for the random
but predictable pattern of addresses:ports used to create an aggregated
trunk.  Since internal bandwidth is greater than the trunk, no work would
need to be done to ensure simultaneous data transfer, however for additional
security some packets could be delayed for out-of-order, fake packets
inserted, etc.  If random ports were used for a parity packet (as in parity
blocks in a RAIDset), lost data on down links could be recalculated without
retries.  To reduce DOS vulnerability, the whole spectrum of port numbers
could be used for the IP addresses involved, and if used for point-to-point
only, could be filtered anyway.  No single link would give enough data to
construct a valid packet.

I'm thinking about this since I'm working on creating WAN connections for a
foreign banking application (VSAT, Landline, etc), and would rather use
IP/IPsec links than X.25, Frame-Relay or SNA/SDLC.  A PKI-enhanced VPN would
route over a RAIFset, which then uses parallel IP or IPsec links.

              (3-8 links?)
               /-Pa---->\
---Packet->RAIF-------ck>RAIF-->Packet
               \---et-->/

Bill Stout


> ----- Original Message -----
> From: Stephen P. Berry [SMTP:spb () meshuga incyte com]
<snip>
> I've used similar techniques for concealing (or obfuscating, anyway)
> the movement of data from one place to another.  I.e., when I want
> reasonably synchronous notification of some event from some sensor, but
> don't want to advertise the fact that the sensor is looking for events
> of that type.  In such situations, generating some decoy traffic is
> generally useful.
>
> If you're interested in muddying the waters beyond the portdancing
> the RAID firewalls (firewobbles?) are doing, using some fraction
> of the free bandwidth between them for decoy traffic might be
> attractive---especially if you have any nagging concerns about
> that PRNG you've got picking your ports for you.  Presumably your
> protocoal for all this would include some mechanism for negotiating
> the `what's and `where's for the decoy traffic---so you can distinguish
> between decoy traffic and spoofed traffic.
>
>
>
>
>
>
>
>
> - -Steve
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQCVAwUBNsJM9Crw2ePTkM9BAQHHAwP8D3fS19Tv3KDlSPXZ6bKxpEdcwxZfDZyl
> OHXo7o6DkjWLk7iwzbS4OJnXEbIE6EtmggjF6eQeeXjT7UUwBH48MOtPr1MlCPyn
> XRB+FrpLGMoSP1Bx8P9vAofFS56pEYqLksxWW3sgy7YQvcUjiHBURcOqATVPn6Gn
> gbd0if32+fo=
> =j9P3
> -----END PGP SIGNATURE-----
> ----- End Of Original Message -----