> > I consider "traceroute -g intermediary destination" to be a ligitimate use
> > of source routing, even when the intermeidary is a non-routing host.
> 
> If it's a non-routing source, what business do your packets have passing
> through the box?

Suppose a user on host X is having trouble reaching site Y.  Perhaps I can
go to host X and try "traceroute Y" to get some hints about where the
packets are going, or perhaps I can ask the user to try that and report
the results to me, but perhaps I have to go to some third host and try
"traceroute -g X Y" to try to discover what happens to packets from X to
Y.  That works only if host X supports LSRR.  Similarly, it often happens
that I can't go to host Y to do "traceroute X", but I can do "traceroute
-g Y X" to try to see what happens to packets from Y addressed to X.

What I am saying is that there is at least one useful and legitimate use
of LSRR packets through a non-routing host, and that it should ideally be up
to the host administrator to permit or deny that use.

> > When GATEWAY is off, the box should not pass packets in one interface and
> > out another, but I think it could still pass LSRR and SSRR packets in one
> > interface and back out the same interface; there could be another option
> > to disable that too (for use in firewalls etc.). 
> 
> This is a nice concept but has a big problem.  The ip_input() routine
> (the function that decides to route or drop or accept as local any incoming
> IP packet) has no sure knowledge of which interface that packet actually
> came in on.

That could be changed.  Before it is changed, I agree that LSRR is a
security risk on multihomed non-routing hosts, but even so, I think it
should be up to the host administrator to permit or deny it.

--apb (Alan Barrett)