North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Telco's write best practices for packet switching networks
On Mon, 11 Mar 2002, Sean Donelan wrote: > > So, i would say i'm pro-OOB where it concerns clean confinement of control > > traffic into a non-routable, unconditionally-prioritized frames, and > > contra-OOB when it comes to making separate networks for control traffic. > > Your definition of "separate network" may vary :) > Of course, like many things security looks easy until you have > to do it yourself. So I don't mean to suggest there are any > really any easy answers. It would help if equipment vendors made it easier to enable management on a per-interface basis, so you could just disable it on "in band" interfaces. > My simple question is why do exchange point prefixes or backbone > network prefixes need to be announced to peers or customers? If no > one announced IXP prefixes, it would be more difficult (modulo > LSSR/SSSR) to send bogus packets at distant routing gateways. The > attacker would need to be directly connected, or compromise something. Define "need". It is extremely helpful to receive ICMP messages from within the IP address range of an exchange. If the routes aren't announced, packets from these addresses would be dropped by routers performing unicast RPF checks. Too bad for traceroute, but potientally much more serious for path MTU discovery. Nearly all implementations are broken to the degree they can't recover from the situation where they don't receive "datagram too big" messages, and exchange points are typically the places where networks with different MTUs come together. I think I would prefer to just announce the prefixes, but route them to the null interface somewhere. This doesn't get in the way of unicast RPF elsewhere, but protects the interconnect addresses equally well, and it allows a more fine grained approach. Anyway, I feel the effort needed to educate networks about this problem would be better spent in trying to get them to filter out outbound packets with bogus source addresses. I still see lots of 192.168/16 source addresses in packets received from peers.