On (04/13/10 10:00), James Carlson wrote: > > So when host1 go to respond, we'd look up a route in the strong-es mode > > first, and assuming that there are no bugs in the src-address selection > > (there were none when I tested this!) code, host1 would pick x.x.y.host1 > > as the src address, B as the outgoing interface, and lookup a route for > > dst/mask = x.x.y.host2/24, interface = B. And we would find the > > interface route over the default route. > > No. If Host 2 is using either TCP, SCTP, or ICMP, this isn't true. > It's also not true if Host 1 has an actually RFC 1122 compliant > implementation of UDP, and sets its source IP address in its replies to > match the destination in the original request. : > If it's at all possible to choose a shorter prefix instead of a longer > one due to the operation of this "src-priority" mode, then I disagree. : > When I match a single more specific route, I expect the packet to go > there, regardless of source. I would be shocked to see the packet > hijacked and sent out some other interface merely because the source > address happens to be equal. I have a hard time understanding how such > a mode would be useful. (And why someone wanting behavior like this > wouldn't just configure Strong ES instead, as it sounds like that's what > they're really after.)
Even in strong ES mode, if the sending host (for whatever reason) picked a src of x.x.x.host1, and dst x.x.x.host2 for a packet it originated, why wouldn't we end up with the routing loop that you flag below? > > Note that, if, for whatever reason, host1 was trying to send out a > > packet to x.x.y.host2 with src address x.x.x.host1, then yes, we would > > send it out on A instead of B. But then again, when you pick a src > > of x.x.x.host1 and send it on B, how would you know that there are > > no ingress filters on B that will drop your packet because your src > > address looks spoofed as defined in rfc 3704? > > I'm not sure I follow. What's the difference between spoofing and > normal IP routing? Can you clarify how that's an issue here? Sitting on host1, if I have a packet with src = x.x.x.host1, dst = x.x.y.host2, how do I know that there is no ingress filter in the path "B" that would drop my packet (per rfc 3704) because x.x.x.host1 is not an address on subnet "B"? the intended purpose of the "src-priority" model is this: if there are multiple routes for the same dst/prefix, we prefer the routes that give a src-addr match first. If no such routes are available, instead of dropping the packet, we pick a route as in the weak hostmodel case. In the case where there is a shorter matching route that allows a srcaddr match (the default route in your example), we prefer that over a possible longer-matching prefix on the assumption that the shoter-matching/default router may have other paths for the dst that would not be choked by rfc3704-based filters. > In any event, what you're suggesting leads directly to a forwarding > loop. If Host 1 sends the packet out on network A, then the router it > sends it to will find that Host 2 is reachable only through Host 1. > It'll send the packet back to Host 1, which will then erroneously > forward it back out on network A -- looping until the TTL expires. Not actually. Since this is hostmodel behavior, it does not apply to forwarded packets- thus if/when the packet loops back to host1 the first time (host1 -> rtr -> host1) it's a forwarded packet, as far as host1 is concerned. Thus it would not be subject to the hostmodel solution proposed here, and would instead get forwarded down B (based on longest prefix match). If there was an ingress filter on B, the packet would get dropped, but that would happen only if the default router for host1 itself did not have any other path for x.x.y.0/24 other than the doomed one through host1 itself. --Sowmini _______________________________________________ networking-discuss mailing list [email protected]
