See also: CR 4974435 Maybe it's better to just let ipf do this, as Jim suggests in the CR?
--Sowmini On (03/03/09 17:39), Erik Nordmark wrote: > > 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?
