> I was just asking whether you thought the logic applied to source
> routing (as in ICMP, which uses the options you note below) applied
> in this situation.  If I understand your reply, the answer is no,
> they are not comparable situations.

Right.

The hazard with SSRR and LSRR is that ip_src as it appears in the
packet received by the destination host refers to the last-hop host,
not the original-source host.  This can fool software that makes
decisions based on ip_src without checking for the presence of
source-route options.  (There isn't all that much such software left;
when the issue first arose, it was significantly commoner, and indeed
one then-common piece of remote login software made authorization
decisions based on that.  This is why the foofooraw over source-routed
(in that sense) traffic.)

This does not apply to making routing decisions based on ip_src.  In
the presence of SSRR/LSRR traffic, it will route based on the last-hop
source address rather than the original source address, but that's how
[SL]SRR are supposed to work.  If all addresses involved are globally
routable, making routing decisions based on ip_src won't affect what
host the packet gets to, only how it gets there (and, in the presence
of losses, possibly _whether_ it gets there); the worst security hazard
this entails is that if a packet takes an unexpected route it may be
snooped (or even actively attacked) by someone unexpected.

If there exist two different hosts that have the same address from the
point of view of the sender - which can happen if, say, you are
speaking "behind the scenes" to two different organizations that each
use RFC-1918 private space - then routing based on ip_src can affect
which host the packet is delivered to...but in that case, that's
presumably what you want, or you wouldn't do it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B