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

2. Page 2 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 3 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 4 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 5 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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 Transport links In-band or in-fiber Out-of-fiber Dedicated link Out-of-fiber Control network NMS In-band or in-fiber ring GMPLS Separation of Control and Data Channels

6. Page 6 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 7 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 8 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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 channelControl plane data links

9. Page 9 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 10 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 11 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 12 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 13 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 14 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 15 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING 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. Page 16 iPOP2008, 5-6 June. 2008, Tokyo, Japan OLD DOG CONSULTING Questions adrian@olddog.co.uk