Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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

  • From: Vadim Antonov
  • Date: Fri Mar 08 20:57:41 2002


There are four different issues with IB vs OOB signalling & control, 
actually --

1) isolation of control traffic from payload traffic to eliminate 
   possible security breaches.

2) isolation of control traffic from payload traffic to prevent starvation 
   of control traffic by (possibly misbehaving) payload traffic.

3) having an alternative, isolated, routing infrastructure for control
   traffic which can function even when primary routing is hosed.

4) having a physically separate network for control traffic which can 
   concievably survive when primary network is broken.

On #1, Internet routing protocols are notoriously weak. Using globally
routable frames to carry neighbour-to-neighbour routing information is a
recipe for disaster (i think everyone on this list can think of few
not-yet-plugged holes arising from this approach).

In most IGPs and eBGP there's simply no need to use routable IP packets,
period.  The only exception is iBGP hack (and consequent route-reflector
kludgery), and this can only be cured by a better-designed IGP which can
carry all exterior routing information. I hope someone's doing something
to make it happen.

Using non-IP packets does not always bring isolation; OSI stack is even
more vulnerable.  So a cheap fix would be to design routing hardware in a
way forcing some reserved IP addresses to be non-routable. (127/8 seems to
be a good candidate :).  Even better is to start using non-IP frame types
altogether.  With all its weakness, outside attacks on ARP are unheard of.

Another (weaker) option is to use cryptography.  Besides inevitable bugs 
(like numerous problems in SSH), crypto is slow and hard to do right.

#2 is also a known pitfall (hello, OFRV :)  Although, in theory, just
jacking up priority on packets carrying routing protocols & network
monitoring traffic could take care of this problem, the reality is quite
hairier.  Most hardware doesn't prioritize generation of ICMPs (so a lot
of looped or misdirected packets can swamp the routing processor which is
incidentally used to separate control traffic from transit traffic).
Usually, there are cross-interface dependencies resulting from shared
buffer memory, the supposedly "non-blocking" switching fabrics being
anything but, confusion between queueing and drop priorities, plain broken
design of packet classifiers (hard to do it right at high speeds :), and
simply network admins being lazy to configure interface ToS processing
appropriately (and/or failing to filter out packets with ToS similar to
the routing protocols' at all ingress points!)

Given the practical problems of getting ToS for control traffic being set
up properly, the option of guaranteeing bandwidth and processing capacity
to control traffic by using separate, non-configurable forwarding/queueing
for non-IP traffic seems to be quite reasonable.

Problems arising from control traffic starvation are numerous and can 
easily lead to prolonged network-wide failures.  Therefore, making control 
traffic "OOB" is definitely worth-while.

#3 is somewhat muddled by the fact that having valid routing information
while having no functioning payload pathway is somewhat irrelevant (in
theory, haiving such information may let network to use
unidirectionally-broken paths, or allow faster recovery from network
fractures by eliminating the need to send updates about _working_ parts of
the split-off networks).  In practice, the only real gain from a redundant
control network is the ability to better diagnose problems, particularly 
routing problems in the primary network (i.e. the "OOB" network is used to 
carry diagnostic traffic only). A dedicated OOB network for console access 
to various pieces of equipment is a lot more useful.

The horrible weakness of SNMP makes separate control network somewhat more
resistant to attacks; however, it also requires zealous filtering of SNMP
and other control protocols (such as telnet :) packets coming to the
router's control unit(s) from the primary network.  If such filtering is
broken or glossed over, there are no security gains.

#4 is hardly useful in any situation (with the exception of diagnostic
network).  In fact, telco-issue "OOB" is usually muxed over the same
wires.

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 :)

--vadim





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.