--pgp-sign-Multipart_Mon_Apr_18_17:19:18_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "js" == Jonathan Stone <jonathan@dsg.stanford.edu> writes:

    js> such an API, combined with applications aware of it, is a
    js> *much* better solution than bogusly glomming IPv6 semantics
    js> onto IPv4,

solution to what?

I tried to read your reference, but:

$ grep -i "strong host" rfc1122.txt | wc -l
       0

As I understand it from context only, the strong host idea is an end
system (ip fowarding off) plugged into both a secure network and an
insecure network, distinguished by physical interface, that remains
secure by binding vulnerable applications only to the secure network.
Feel free to correct me.

This:

 (a) contradicts best-common-practice, which is to use intermediate
     systems at the boundaries of secure networks, and plug secure
     hosts into secure networks only.

     If you have some new idea that you think is better than
     firewalls, that's great, but glossing over the fact that it's
     tremendously disruptive to a ponderous (slow-to-change) industry
     with immediate needs is unrealistic.

 (b) doesn't generalize to interfaceless IPsec tunnels, which is the
     most common case I can imagine where such ideas would actually be
     useful on an end system now.

 (c) does not solve the problem David asked about, and thus is not a
     ``solution.''

 (d) could be presented just as well with less snarkyness.

but that's just my ill-infored opinion.  I haven't followed the OSI
travelling standards circus, so I've no doubt missed a lot of
interesting unimplemented stuff.

In any case, source address selection is obviously a FAQ around here
with one or two questions per month about it, and one or two people
who haven't tried it each time answer ``use -ifa'' which does not
work.  A solution that requires modifying every application to make
some ioctl is disingenuous and obstructionist.  The first step is
admitting you have a problem, and we haven't got there yet.  so let's
talk about solutions after we agree on the problem's existence.

--pgp-sign-Multipart_Mon_Apr_18_17:19:18_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQCVAwUAQmQkVonCBbTaW/4dAQJ/ewP9HdnE2JgxomYKAQ+qvWjOdXM4jPprBNX/
ibcjV4mo2THh0CKWFIfbO6SI7G1XRn14CqWsKEQBoyZ4XLb6bxx3mw23s2/E/cTF
nFYR5BfnSsbibW3qdfsi1NxM8D9y+sElwTL0ZkHglgWnJwqVUccL7ytEHfqosOVw
T+XV7IXSnCA=
=146d
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Mon_Apr_18_17:19:18_2005-1--