Control Plane Resilience and Security in GMPLS Networks: Fact and Fiction

1. Control Plane Resilience and Security in GMPLS Networks: Fact and Fiction Adrian Farrel Old Dog Consulting (adrian@olddog.co.uk)

2. Agenda • Control of Legacy Transport Networks • MPLS Control Channels • GMPLS Separation of Control and Data Channels • What is a Control Channel? • Risks, Resilience, Attacks, and Potential Damage • How are Control Channels Made Resilient? • How are Control Channels and Protocols Protected? • Summary: Where Should We Focus Our Efforts?

3. Control of Legacy Transport Networks • Configured and operated from an NMS (or through EMS) • Management channels • Dedicated links, in-band or in-fibre with data, through a private out-of-band management network • Security achieved through point-to-point relationships • Such as IPsec, access lists, and passwords • Management plane resilience • Low priority • Enabled through parallel or back-up links • Data channels continue to operate after management plane failures • Devices can be managed after data channel failures

4. MPLS Control Channels • MPLS is closely tied to IP • The MPLS packets use interfaces identified by their IP addresses • Control packets (LDP or RSVP-TE) use the same interfaces and addresses • The health of the control channel correlates to the health of the data channel • Data channel failure implies inability to deliver control messages • Control messages are always single-hop IP messages • Data plane forwarding fails when control plane fails • A single “keep-alive” mechanism can be used on the data/control channel • Data plane mechanisms • IGP keep-alive • BFD • Do not confuse control channel failure with control protocol failure! • Protocols now support continuous forwarding and protocol restart • Component failure • Software upgrade or restart after failure

5. GMPLS Separation of Control and Data Channels • Control plane connectivity between neighbouring switches • Multiple parallel control plane connections may exist • GMPLS switches can be packet routers in the control plane • The health of the control channel does not correlate to the health of the data channel • Data continues to flow even when the control connection is down Out-of-fiber Control network NMS Out-of-fiberDedicated link In-band or in-fiber ring In-band or in-fiber Transport links

6. What is a Control Channel? • A logical association between two control plane entities that need to communicate. • This is an IP network, so a control channel is just a pair of IP addresses in the control plane • What is it not? • It is not a data link in the control plane • Although it might be! • What can you do? • Assign “always reachable in the control plane” IP addresses for the ends of control channels • TE Router ID does the job • Use interface addresses for the ends of control channels • Must be packet-capable interfaces! • Could be individual control plane data links, or bundles

7. Risks, Resilience, Attacks, and Potential Damage • Important to understand the concerns • Data plane failures • Will data channel failure make equipment unmanageable? • Control plane failures • Will control plane failure impact traffic? • If the control plane isn’t recovered rapidly, what function will I lose? • Do I need to provide resilient or backup control channels? • Security • What is the control plane security model? • What might happen if the control plane was attacked? • How do I protect the control channels?

8. How are Control Channels Made Resilient? • Resilient control plane data links • Just one control channel • Apply normal link protection mechanisms to data links in the control plane • When one link fails, traffic is seamlessly switched to another • Protection can be 1+1, 1:1, etc. • Control plane protocols can survive failover • Control plane has low throughput • Failover unlikely to drop more than one packet • Control plane protocols include retransmission mechanisms • Control plane data links may be in separate data fibers, etc. Control channel Control plane data links

9. The Self-Healing Control Plane • IP networks are “self healing” • The IGP (OSPF or IS-IS) determines new shortest paths • Convergence times are short • Transport networks are not large by IP standards • We only need local convergence • Most control plane messages are being sent a short distance • Control plane protocols can survive faults in the network • All of the GMPLS protocols are designed to survive IP’s unreliable delivery • Make your control plane network a proper IP network • Provide multiple IP interfaces to a node • Run an IGP in the control plane (you have to anyway for TE distribution) • Use stable IP addresses for the control channel (i.e. TE Router ID)

10. Common Control Plane Failure Questions? • What if RSVP-TE detects a soft-state timeout? • Will not happen • Soft-state timers are much larger than repair times • RSVP-TE Hello timer will fail first • Soft-state cannot time out when Hellos have failed • Will RSVP-TE Hello re-establishment cause protocol restart? • No • Hello recovery will use the same epoch number • (But anyway, protocol restart is now graceful) • Doesn’t LMP detect errors very fast and switch to a new control channel? • It can do, but it is your choice • Depends on how you build your control channels

11. LMP Control Channel Management • LMP recognizes that managing multiple parallel control plane data links may be a burden • If this can be done in the data link layer, then no issue • If this can be done using the IGP, then no issue • But what if there are very many potential control plane data links? • For example, tens of parallel fibers • Don’t want to advertise these all to the IGP at the same time • LMP assigns addresses to control plane data links • Numbered or unnumbered • One control plane data link is used and monitored using Hellos • On failure, another one is brought up and given to the IGP • Control channel end-point (i.e. TE Router ID) reachability is maintained

12. How are Control Channels and Protocols Protected? • All GMPLS protocols apply security between neighbors • Nearly all message exchanges are between neighbors • Access lists a re common and easy to apply • But auto-discovery can discover a fake neighbor! • Authentication and integrity checks in all protocols • Requires a password pairing for all neighbors • Configuration burden? • Temptation to use network-wide keys/secrets • Full security through IPsec • Similarly requires password pairing for all neighbors • All mechanisms work through IP clouds • Other tunneling and VPN techniques are also available • Automatic key distribution mechanisms are available

13. What are the Security Risks • GMPLS networks have a “chain of trust model” • Chain is as strong as its weakest link • Access anywhere in the network can attack the whole control plane • Tapping into a control channel • Easiest when the control channel goes through an IP cloud • Allows snooping and all forms of attack • Easiest attack is denial of service • Makes it hard to manage existing LSPs or set up new ones • Effect of other attacks may be • Redirection of user traffic • Degradation of customer quality • Theft of network resources • So why don’t we enable security in the control plane? • Is no-one worried about security? • Are network operators used to relying on simple management plane relationships? • Do operators think that their control networks are private? • Is it too hard to configure and manage security? • Are implementations deficient?

14. Summary: Where Should We Focus Our Efforts? • We do not need to spend any more time discussing control plane resilience • The GMPLS control plane is resilient • We must model the control plane network • Understand the vulnerabilities of the network as a whole • We need to understand security risks to the control plane • Requires analysis of many different possible attacks • Install and test adequate security techniques • Operators must state what they need • Vendors must implement the necessary mechanisms • Secure networks can only be built from equipment that supports the same level of security

15. References • RFC 3209 • RSVP-TE Specification • Defines timer procedures and introduces Hello • RFC 3473 • GMPLS RSVP-TE Specification • Defines control and data plane separation • Refines Hello procedures • RFC 4204 • LMP Specification • draft-ietf-mpls-mpls-and-gmpls-security-framework • Explains the security models and techniques for GMPLS and MPLS

16. Questions adrian@olddog.co.uk