In article <v01510102abccf245606f @
130]> you write:
>Milkyway Black Hole
> - Supports modified (proprietary) DES algorithm (DES++).
This is DES with some trivial obscuring code, we haven't modified
the code code.
We would like to support GSSAPI on top of a swIPe-like facility, but
since swIPe doesn't define any standard encryption yet, we are waiting
for an available commercial GSSAPI. (e.g. NT Entrust)
I suspect this will be the solution for interoperability.
>configuration is the same at each of the nodes. At the present time, a
>user must go through a challenge/response sequence at each firewall. The
>customer is exploring security technologies that could eliminate the need
>for a challenge/response dialogue at each firewall.
Essentially all virtual private network software winds up doing a
small amount of packet filtering/routing to get the packets to the
remote network to go through the encryption engine.
In Black Hole, if you decide *not* to trust the packets coming from
the "encrypted virtual interface", then they don't get routed, and
must pass through the normal Black Hole proxies. e.g. branch office
can login to HQ, but they must authenticate, and their packets get
encrypted so no one can hijack the connection.
Or, you can just route the packets.
:!mcr!: | <A HREF="http://www.milkyway.com/">Milkyway Networks Corporation</A>
Michael Richardson | Makers of the Black Hole firewall
NCF: aa714 || xx714 | +1 613 566-4574 ... mcr @
Home: <A HREF="http://www.sandelman.ocunix.on.ca/People/Michael_Richardson/Bio.html">mcr @
ca</A>. PGP key available.