For a long time Solaris has had a ndd knob called
ip_strict_dst_multihoming, which if enabled makes sure that unicast
packets are not accepted if they are received on an interface which
doesn't match their IP destination address. This is sometimes enabled to
improve security.
The strong end-system model (see RFC 1122) talks about restricting
things both at the receiving and sending ends, and we have some RFEs
asking for that. What this means in practice is that the source IP
address constrains the interface on which the packet can be sent out,
whether the source IP address was set by the application (doing a
bind()), or set as part of accepting a new TCP/SCTP connection.
So far our answer has been "given our current complexity that would be
near impossible" (due the IRE_CACHE entries getting in the way in far
too many ways.)
I was reminded of these RFEs last week, so I went and looked at how hard
it would be to implement this on top of the changes being done for the
IP Datapath Refactoring project, and it doesn't seem very hard; in about
300 lines of added code we can make this work.
What I've prototyped has two ndd variables (to mirror the
ip*_strict_dst_multihoming):
ip_strict_src_multihoming for IPv4
ip6_strict_src_multihoming for IPv6
One detailed question is how the system should work on a Solaris box
configured as a router. For ip*_strict_dst_multihoming we accept the
packet if both the arriving interface and the interface on which the IP
address is configured has ILLF_ROUTER set. Do we need to do the same
check for ip*_strict_src_multihoming, or is it sufficient to check if
the interface on which the packet is sent has ILLF_ROUTER set?
Erik
