Page 1 OLD DOG CONSULTING Control Plane Resilience and Security in GMPLS Networks: Fact and Fiction Adrian Farrel Old Dog Consulting ([email protected])

Page 1 OLD DOG CONSULTING

Control Plane Resilience and Security in GMPLS Networks:

Fact and Fiction

Adrian Farrel

Old Dog Consulting([email protected])

Page 2iPOP2008, 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?


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


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


• 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-fiberDedicated link

Out-of-fiber Control network

NMS

In-band or in-fiber ring

GMPLS Separation of Control and Data Channels


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


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?


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


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)


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


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


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


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?


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


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


Questions

[email protected]

Documents

Page 1 OLD DOG CONSULTING Control Plane Resilience and Security in GMPLS Networks: Fact and Fiction Adrian Farrel Old Dog Consulting ([email protected])