In message <oq1x97u6jt.fsf@castrovalva.Ivy.NET>,
Miles Nordin writes:
>--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?


Attempting to route packets based on the local IP source address as
well as the destination address. (or, on reception, to allow reception
based on whether the the destination IP address matches the local
address of the interface on which the packet was received, instead of
any local address of the host.

Which, as is spelled out below and in RFC-1122 (section and page
numbers below), is *exactly* what Strong End-Host is all about.


>I tried to read your reference, but:
>
>$ grep -i "strong host" rfc1122.txt | wc -l
>       0

If you're that, um, lazy (see below), then a more fruitful pipeline is:

	grep -e 'strong ES' rfc1122.txt | wc -l
	4
or see section 3.3.4.2, Multihoming Requirements, p. 62-64. Heck, even

	grep -e 'strong' rfc1122.txt 

yields only 6 matches, one of which is `strongly'; of the other 5, all
but one say "Strong ES", and the last one clearly is talking about TCP
MSS. So the appellation "lazy" seems like a fair cop to me.



>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.

Nope, thats not correct. Here's a stab at a correction:

Strong End-host on the one hand, and Weak End-host on the other, are
two different conceptual models of multihoming.  (I can't do better
than the cited pasage of the RFC; please read that now, if you haven't
already.)

TO Conflate Strong End-host model soley with security is an error:
there are valid, but non-security relevant, uses of Strong End-host
model.  The classic example is failover to a different IP address:
under Strong ES, if your peers start talking to you on a different
interface (and thus via a different destination IP address), you must
send back to them *on that same interface*.  Hence, as RFC-1122 notes,
Strong End-Host logically implies a default next-hop IP route (really,
a route table) *per interface*.  Or rather, per local IP address.

Further conflating Strong/Weak End-host with the RFC-1918 allocation of
private IP addresses only aggravates the initial error.

I don't use IPv6 enough to comment on whether that's an understandable
or forgivable error, given familiarity with IPv6 but not IPv4. Even if
it is, I submit that, if one is going to comment on how IPv4 should
work, then one has an onus to understand the relevant RFCs; which
*most* definitely includes RFC-1122.


[[Skip most of the rest, as being based on an incorrect assumption of
  what Strong End-Host is.]]

At this point it's only fair to add that emulating Strong End-Host on
a *BSD stack tends to run into problems. Most of which are solvable,
or have been solved, in some *BSD stack or other. But the requirement
to do route lookups based on

	(src IPaddr, dst IP addr [, TOS])

instead of just

	(dst IP addr [, TOS])

hasn't ever really been addressed, as far as I know.  (At least, not
since the Patricia-tree routing table with integrated ARP lookup.)



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

I saw a strong claim about what an IP/TCP stack (or NetBSD's IP/TCP
stack: you be the judge) "should" be doing. (Insert "v4" after IP if
required).  As far as I can tell, that strong claim was made from a
position of thorough-going ignorance about RFC-1122; one of the most
fundamental RFCs on IPv4 issued over the last 15 years.

I don't know about you, but I find that tantamount to

	``I don't know enough about IPv4 to hold an informed opinion;
	  but neverthess I assert our IPv4 stack should do ....'',

which, I submit, is offensive.  In contrast, a non-offensive note like
yours, which spells out where assumptions are being made, deserves an
informative, helpful, and hopefully polite reply.