Transcript Control Plane Resilience and Security in GMPLS Networks: Fact

Control Plane Resilience and
Security in GMPLS Networks:
Fact and Fiction
Adrian Farrel
Old Dog Consulting
([email protected])
Page 1
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?
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 2
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-ofband 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
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 3
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
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 4
OLD DOG CONSULTING
GMPLS Separation of Control and Data Channels
Out-of-fiber Control
network
NMS
Out-of-fiber
Dedicated link
In-band or in-fiber ring
In-band or in-fiber
Transport links
•
•
•
•
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
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 5
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
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 6
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?
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 7
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 channel
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Control plane data links
Page 8
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)
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 9
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
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 10
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
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 11
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
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 12
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?
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 13
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
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 14
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
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 15
OLD DOG CONSULTING
Questions
[email protected]
iPOP2008, 5-6 June. 2008, Tokyo, Japan
Page 16
OLD DOG CONSULTING