[email protected] wrote: > On (04/13/10 10:00), James Carlson wrote: >> 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?
I'm confused about the case you're suggesting, but I don't think it happens. Host2 (connected only to network B in my example) sending to Host1's A-side address would find that its packets are dropped because they don't exactly match the address on the local receiving interface (on network B), and Strong ES disallows that. I think you're talking about a case where Host1 chooses to bind its A-side address and then talk to Host2. Such a packet would (I expect) ordinarily be sent through the B network to reach Host2, but then replies from Host2 would be dropped as above. Strong ES guarantees a lack of connectivity (if nothing else). If Host1 were set up for Strong ES and really did erroneously send a packet destined for Host2 out onto network A (I don't see why it would do that), then the next hop router on network A would forward that back to Host1. At that point, it's unclear to me if we get a drop or a loop, because I don't understand why Host1 would ignore its own routing table even with Strong ES enabled. Ignoring standard IP routing seems like a mistake to me. >>> 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"? You can't know. But it doesn't matter. If such a filter were installed, then Host2 would be unable to communicate with ANYBODY outside of network B. Such a filter would make all routed packets destined for Host2 drop, and network B (in the diagram I gave) was Host2's only connection to the world. No communication == you got what you wanted (or deserved) for configuring such a filter. > 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. That's how you've defined it to operate. It doesn't describe to me how it might be used. Can you give an example where it would work properly, but the "source preference" model I suggested would not work? > 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. I still don't get what problem this mechanism solves. An RFC 3704 filter would naturally exist at some sort of network administrative boundary, when you (the filtering party) *know* that the guy on the other side shouldn't be doing any routing. He's a stub network to you, so you know his source addresses are constrained. In the "source preference" case I cited, that's neatly solved by having two default routes -- equal prefix length -- pointing at two different ISPs, each possibly doing RFC 3704 filtering on our source addresses. When we send packets (either generated locally or forwarded) to the Internet, we see the two default routes, equal prefix, and choose among them properly based on source address. Packets we send always end up on the right interface. If there are any more specific routes then either (a) the user knows what he's doing and points those routes where they go, (b) the user provides multiple such specific routes so that the source preference is obeyed, or (c) the user is clueless and gets what he asked for, but not what he wanted. I don't see how you can save the user from RFC 3704 issues by forwarding in direct contradiction of the standard IP forwarding rules, but I *do* see how you can form long-lived forwarding loops or really confused routing by doing so. Thus, I don't think the current design makes sense. >> 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. So locally-emitted packets are forwarded differently than those received from elsewhere? That's new RFC 791 / 1812 behavior, and makes even less sense to me. Consider another router/host, call it "myhome," that is connected to two ISPs for redundancy, and that has subnets configured behind it on another interface. When "myhome" originates packets to the Internet using the scheme you're advocating, it'll always pick the right interface. But when it forwards packets from the internal networks to the Internet, it'll do so incorrectly. It won't obey the source address restrictions, merely because these packets are forwarded, and they'll end up on arbitrary output interfaces, and be sometimes dropped on RFC 3704 filters. I think this feature may need to be rethought. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ networking-discuss mailing list [email protected]
