North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Telco's write best practices for packet switching networks
- From: Iljitsch van Beijnum
- Date: Mon Mar 11 07:41:27 2002
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"
> 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.