[email protected] wrote: > On (04/13/10 08:06), James Carlson wrote: >> This means that Host 1 will have a default route pointing somewhere on >> network A, and an interface route pointing to x.x.y.0/24 for network B. >> Host 2 will have a default route pointing to Host 1's address on network B. >> >> What happens if Host 2 sends a packet to Host 1's address on network A, >> and then Host 1 goes to respond? It sounds like you're saying that > > Host 2 would presumably have used the src address x.x.y.host2.
Yes. > 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. The obvious problem, though, is with TCP. There's no way Host 1 gets to choose a new source address with any connection-oriented protocol, so this can't work. >> we'll discover the default route _before_ the interface route, and we'll >> see that the interface address matches and thus send the packet >> (erroneously) out on interface A. > > I don't see how this would happen. Could you clarify? TCP? >> preference" (i.e., if there are multiple matching routes that are >> exactly equivalent -- same prefix length -- then choose the one with an >> interface with the same source, and if no such interface, then choose > > But that *is* exactly what it is. 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. The only sort of "src" mode I would like to use (and that I expected to see implemented one day) is one where we always pick the longest prefix -- so that routing still works properly and doesn't result in unexpected forwarding loops -- but which is able to choose wisely among multiple prefixes of exactly the same length. That's exactly the multi-homing problem. I have two addresses (call them "A" and "B") from two different ISPs, and these are configured through two separate interfaces. I have default routes pointing to both interfaces, because both of those interfaces go to "the Internet." All default routes are equal in prefix length (zero), so when I hit the default, I see I have two of them. I would like to prefer that when I'm sending from the "A" address, I send packets out through the "A" interface. (More generally, when the source is anywhere inside the "A" subnet, I want to send through the "A" interface if possible.) 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.) > 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? 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. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ networking-discuss mailing list [email protected]
