In the previous two installments of this series on SDN and NFV I
discussed the virtualization and configuration of communications
functionalities; this installment will deal with their placement. I call this
aspect geography, and this time use the term in its most literal sense – where
geographically a given function should be physically located.
Note that this aspect of a network function is independent of the previous ones. Even a nonvirtualized function implemented entirely in dedicated hardware can still be placed in various places along the communications path. Of course, most functions do have traditional locations - e.g., a firewall is generally placed at the customer network's ingress point, and a pseudowire interworking function is placed at the Provider Edge (PE). But, there is some flexibility in these placements. When the service provider provides the firewall function, it does so by moving this function from the customer premises to the service provider's. If the customer maintains the pseudowire the IWF is placed at the customer premises rather than at the PE.
SDN and NFV herald yet more flexibility. Virtualization of networking functionalities may expose many placement options by offering numerous locations with the resources required to run the Virtual Network Function (VNF). And SDN enables dissociating protocols from their conventional locations; e.g., routing protocols can be removed from routers and run on servers in remote datacenters instead. CPRI goes even further by moving all eNodeB processing (except the antenna, mixer, and A/D) to dedicated hardware at a remote location.
In principle, all network
functions can be virtualized. This statement derives from the computational
universality (technically the Turing completeness) of CPUs. In practice, however, virtualization
of certain functions is not practical (at least not at reasonably high data-rates). For example, while it is straightforward to perform L2 or L3 forwarding at Gigabit speeds on a CPU,
at 10G rates utilizing dedicated hardware is more cost effective, and at 100G
there is presently no option for virtualization. Similarly, certain intensive
operations are more effectively left in dedicated hardware, for example
bandwidth shaping, high-rate CCs for protection switching, and encryption.
What about the geographic positioning of network functions? Can all
network functions be, in principle, arbitrarily positioned? Should they be ?
The three most important factors in determining the desirability of a
property are location, location, location.
-
incorrectly attributed to Harold
Samuel, UK realtor
A residence that perfectly suits your needs can’t
usually be moved it to the desired location. The same is true for certain
networking functionalities. Not every function can be placed anywhere there are available resources. And even for those that can be placed anywhere, there are many reasons to select specific locations.
As an obvious example consider loopback
functionality. Loopback diagnostic testing enables a remote administrator to verify connectivity to and from a remote site. Moving this function to a remote datacenter makes no sense at all! The same can be said for many security functionalities, such as encryption and Denial of Service (DoS) attack blocking. Moving encryption to the other side of an access network leaves unencrypted traffic exposed to all with access to that network, and conversely, blocking malicious traffic at the other side leaves the door open to attackers with access to the network.
Deep Packet Inspection (DPI) provides a slightly less obvious example. Moving a DPI function from the place where it is needed necessitates sending the packets to be inspected to a remote DPI engine, resulting in additional bandwidth consumption and increased processing delay. If the bandwidth is unavailable or too expensive, or if the added delay exceeds the budget for the applications involved, then DPI needs to remain in situ even if computational resources are less expensive elsewhere.
Another placement constraint arises from regulatory issues. For example, certain databases must not be moved across commercial or jurisdictional boundaries. Traffic crossing certain borders may subject parties to taxation. Certain on-line activities may be legal in some jurisdictions but not in others. Requirements for lawful interception may also influence placement decisions.
On the other hand many functions can be placed in many different locations. The most credible cases are routing and path computation, as well as billing/charging. Other innovative placements are being extolled in the press and heatedly discussed in the forums. The security and privacy implications of such placements are only recently receiving attention.
When functions can be placed in many geographical locations, the final placement decision is usually based on economics. Service provider Points of Presence (POPs) and datacenters may be attractive due to the ability to exploit economies of
scale. Real estate expenditures are minimized by colocating as many functions aspossible. Cooling costs may be minimized by running functions in riverside datacenters with water cooling. Placing multiple instances of a function in the same datacenter can hugely simplify management and maintenance.
In fact, many people equate NFV with moving all nontrivial control functionality to datacenters leaving no intelligence in the network. The CloudNFV initiative is based on the tenet that it is most efficient to run VNFs as SaaS. On the other hand RAD believes in Distributed NFV (D-NFV) wherein each function is placed at the position in the network where it can best fulfill its function. That position may be at a CPE, or an aggregation point, or in the network core, or in a data-center.
Another issue complicating placement decisions is function chaining. In many cases there are multiple functions that need to be performed on packets somewhere along the end-to-end path, with restrictions on the order in which these functions need to be performed. These functions may include packet shaping, packet remarking, NAT, intrusion detection, and tunnel encapsulation. We certainly wouldn't want to send a packet to a remote datacenter for intrusion detection, return it for shaping, and then send it back to the datacenter for NAT.
Optimization of function chaining turns out to be more complex than that carried out by a Path Computation Element (PCE). The latter need only find acceptable paths through equivalent routers, while the former needs to handle much more complex paths and constraints.
As an abstract example, imagine that functions A, B, C, D, and E all need to be performed on every packet belonging to a service before final delivery. Function A must be performed before either B or C; B and C can be performed in either order but must be performed before C or D; and E must be the last function performed before delivery. Imagine further that in the network there are numerous devices that are able to perform these functions, but not all devices can perform all functions. Furthermore, the services have delay cutoffs, bandwidth should not be needlessly wasted, and resource loading should be equalized in order to avoid bottlenecks and potential points of failure. Finally, the computation of the chaining order needs to be performed upon intializing a new service, and while changing the service chaining configuration of an existing service is possible, it should be avoided due to the negative impact on service quality.
How does the function chain orchestrator determine the optimal placement of each VNF? I'll discuss that in the next installment.
Y(J)S
Showing posts with label DPI. Show all posts
Showing posts with label DPI. Show all posts
Monday, October 21, 2013
Monday, May 30, 2011
"Seamless MPLS" and Denial of Service
A Denial of Service (DoS) attack is an attack that attempts to render a service temporarily unavailable to legitimate users of the service. DoS attacks are carried out by attackers disrupting the function of any link in the service supply chain. In the context of services provided over telecommunications networks, DoS attacks can be directed at a web or mail server, routers, or at any necessary utility functions such as the DNS system.
There are two main DoS attack strategies :
1. The attacker can send malware to the attacked device, causing its malfunction. In extreme cases (called phlashing) the attacked device may need to be completely replaced.
2. The attacker can flood the attacked device with a large number of seemingly legitimate service requests, thereby consuming its resources and degrading its ability to service other users. In order to more completely overwhelm a device (and camouflaging the source of the attack), Distributed Denial of Service (DDoS) attacks simultaneously send service requests from multiple sources. Rate limiting and traffic shaping are not true DoS prevention methods. First, they are ineffectual against the first type of attack. Second, although they may prevent overload of devices under attack, since they do not distinguish between attackers and legitimate users, they themselves reduce service quality. In addition, they become Achilles’ heels providing attackers with new devices to attack.
There are only two true defenses against DoS attacks :
1. discarding illegitimate service requests,
2. allowing only legitimate service requesters.
The first method is typically used against attacks that exploit packets carefully designed to confuse network devices or require greater than average processing resources. It is ineffectual against brute-force attacks by properly formed service requests, such as DDoS attacks. It also usually requires costly Deep Packet Inspection (DPI). The second method is universally effective, but can only be used when there is a way to accurately identify legitimate users of the service.
That way is called source authentication, and it works by verifying that each received packet was authentically sent by the source claiming to have sent it. Thus source identification is limited to packet formats that include a source address, such as Ethernet, IPv4, and IPv6. IPsec uses a Hash-based Message Authentication Code (HMAC) to verify both the integrity and authenticity of an IP packet. MACsec uses a combined algorithm to verify integrity and authenticity, and optionally encrypting the packet.
As is certainly well-known to readers of this blog, MPLS packets contain labels that proxy for destination addresses, but no explicit addresses, and certainly no source address. As stated RFC 5920 - Security Framework for MPLS and GMPLS Networks :
The MPLS data plane, as presently defined, is not amenable to source authentication, as there are no source identifiers in the MPLS packet to authenticate. The MPLS label is only locally meaningful. It may be assigned by a downstream node or upstream node for multicast support.
When the MPLS payload carries identifiers that may be authenticated (e.g., IP packets), authentication may be carried out at the client level, but this does not help the MPLS SP, as these client identifiers belong to an external, untrusted network.
An attacker with physical access to an MPLS network can readily cause mayhem. There are only a million possible MPLS labels, and thus it will not take an attacker long to come across a valid one. Once that is accomplished, nothing can stop packets he injects from traversing the network and appearing at supposedly isolated egress points. The attack is made even simpler because many LSRs are configured to employ platform-wide label spaces, and many LSR label generators produce labels in order from low to high.
Of course if the MPLS is carrying only IP traffic, then that network layer can be protected using well-known IPsec methods. But MPLS can also carry non-IP traffic, e.g. pseudowires. Imagine what would happen if extra TDM-PW traffic were successfully injected - buffer overflows, loss of timing, and complete service shutdown. Imagine what would happen if an attacker injected multicast PAUSE frames into an Ethernet PW – delayed frames, buffer overflow, and complete service denial.
So why haven’t there been widespread devastating attacks on the critical MPLS infrastructure ? Mainly because MPLS networks have, until now, been walled gardens, that is, closed tightly controlled networks, with no access to outside attackers. RFC 5920 calls them trusted zones, which it describes in the following manner :
A trusted zone contains elements and users with similar security properties, such as exposure and risk level. In the MPLS context, an organization is typically considered as one trusted zone.
The boundaries of a trust domain should be carefully defined when analyzing the security properties of each individual network … In principle, the trusted zones should be separate …
A key requirement of MPLS and GMPLS networks is that the security of the trusted zone not be compromised by interconnecting the MPLS/GMPLS core infrastructure with another provider's core (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users.
So, MPLS has been safe since it has been hidden away in the core, with no access to outsiders.
But this is about to change. The IETF MPLS WG recently elevated to working group status a document entitled Seamless MPLS Architecture (draft-leymann-mpls-seamless-mpls). This document proposes extending MPLS from the core into access networks, and seamlessly integrating the access domain into the core MPLS domain. In the words of the draft :
The motivation of Seamless MPLS is to provide an architecture which supports a wide variety of different services on a single MPLS platform fully integrating access, aggregation and core network. The architecture can be used for residential services, mobile backhaul, business services and supports fast reroute, redundancy and load balancing. Seamless MPLS provides the deployment of service creation points which can be virtually everywhere in the network.
…
With Seamless MPLS there are no technology boundaries and no topology boundaries for the services. Network (or region) boundaries are for scaling and manageability, and do not affect the service layer, since the Transport Pseudowire that carries packets from the AN to the SN doesn't care whether it takes two hops or twenty, nor how many region boundaries it needs to cross.
Seamless MPLS drops the boundaries between access, aggregation, and core networks. This may indeed simplify network management – but how are the security issues handled? The draft’s “Security Considerations” section states the following :
In a typical MPLS deployment the use of MPLS is limited to relatively small network consisting of core and edge nodes. Those nodes are under full control of the services provider and placed at locations where only authorized personal has access (this also includes physical access to the nodes). With the extensions of MPLS towards access and aggregation nodes not all nodes will be "locked away" in secure locations. Small access nodes like DSLAMs will be located in street cabinets, potentially offering access to the "interested researcher".
So far, so good. The draft authors understand the security problem they raise. But now for the punch line …
Nevertheless the unauthorized access to such in device SHOULD NOT impose any security risks to the MPLS infrastructure itself.
The term SHOULD NOT can be understood in two ways. Perhaps it is simply a statement that the authors believe that this placement of nodes in sites where they will be accessible to outsiders simply shouldn’t cause any problems, since no-one would think of attempting to exploit this vulnerability. Or perhaps this is a requirement for implementations, but not a strong MUST requirement, just a SHOULD requirement. In this case the authors are saying that perhaps in some cases it would be a good idea to do something about this, but only if there isn’t some other more important consideration.
But don’t panic - the draft authors add an additional sentence :
Seamless MPLS must be stable regarding attacks against access and aggregation nodes running MPLS.
Note that this requirement carries a non-normative must rather than a MUST. Also, seamless MPLS need not be impregnable to attacks, just stable. Network stability is defined in RFC 2360, the Guide for Internet Standards Writers. It means that the network does not take an infinite time to return to normal operation after some type of change. In this context, it apparently means that after a DoS attack is over, the network should return to normal functioning. Not a very strong requirement !
Can seamless MPLS be made safe (or at least as safe as present networks) ? Of course, but the effort would be substantial, requiring IETF to develop security mechanisms for non-IP traffic, something that has not been attempted to date. As the draft authors requested that the draft be accepted with all the rest of the security section marked “TBD”, fixing this lacuna does not seem to be very high on their list.
Y(J)S
There are two main DoS attack strategies :
1. The attacker can send malware to the attacked device, causing its malfunction. In extreme cases (called phlashing) the attacked device may need to be completely replaced.
2. The attacker can flood the attacked device with a large number of seemingly legitimate service requests, thereby consuming its resources and degrading its ability to service other users. In order to more completely overwhelm a device (and camouflaging the source of the attack), Distributed Denial of Service (DDoS) attacks simultaneously send service requests from multiple sources. Rate limiting and traffic shaping are not true DoS prevention methods. First, they are ineffectual against the first type of attack. Second, although they may prevent overload of devices under attack, since they do not distinguish between attackers and legitimate users, they themselves reduce service quality. In addition, they become Achilles’ heels providing attackers with new devices to attack.
There are only two true defenses against DoS attacks :
1. discarding illegitimate service requests,
2. allowing only legitimate service requesters.
The first method is typically used against attacks that exploit packets carefully designed to confuse network devices or require greater than average processing resources. It is ineffectual against brute-force attacks by properly formed service requests, such as DDoS attacks. It also usually requires costly Deep Packet Inspection (DPI). The second method is universally effective, but can only be used when there is a way to accurately identify legitimate users of the service.
That way is called source authentication, and it works by verifying that each received packet was authentically sent by the source claiming to have sent it. Thus source identification is limited to packet formats that include a source address, such as Ethernet, IPv4, and IPv6. IPsec uses a Hash-based Message Authentication Code (HMAC) to verify both the integrity and authenticity of an IP packet. MACsec uses a combined algorithm to verify integrity and authenticity, and optionally encrypting the packet.
As is certainly well-known to readers of this blog, MPLS packets contain labels that proxy for destination addresses, but no explicit addresses, and certainly no source address. As stated RFC 5920 - Security Framework for MPLS and GMPLS Networks :
The MPLS data plane, as presently defined, is not amenable to source authentication, as there are no source identifiers in the MPLS packet to authenticate. The MPLS label is only locally meaningful. It may be assigned by a downstream node or upstream node for multicast support.
When the MPLS payload carries identifiers that may be authenticated (e.g., IP packets), authentication may be carried out at the client level, but this does not help the MPLS SP, as these client identifiers belong to an external, untrusted network.
An attacker with physical access to an MPLS network can readily cause mayhem. There are only a million possible MPLS labels, and thus it will not take an attacker long to come across a valid one. Once that is accomplished, nothing can stop packets he injects from traversing the network and appearing at supposedly isolated egress points. The attack is made even simpler because many LSRs are configured to employ platform-wide label spaces, and many LSR label generators produce labels in order from low to high.
Of course if the MPLS is carrying only IP traffic, then that network layer can be protected using well-known IPsec methods. But MPLS can also carry non-IP traffic, e.g. pseudowires. Imagine what would happen if extra TDM-PW traffic were successfully injected - buffer overflows, loss of timing, and complete service shutdown. Imagine what would happen if an attacker injected multicast PAUSE frames into an Ethernet PW – delayed frames, buffer overflow, and complete service denial.
So why haven’t there been widespread devastating attacks on the critical MPLS infrastructure ? Mainly because MPLS networks have, until now, been walled gardens, that is, closed tightly controlled networks, with no access to outside attackers. RFC 5920 calls them trusted zones, which it describes in the following manner :
A trusted zone contains elements and users with similar security properties, such as exposure and risk level. In the MPLS context, an organization is typically considered as one trusted zone.
The boundaries of a trust domain should be carefully defined when analyzing the security properties of each individual network … In principle, the trusted zones should be separate …
A key requirement of MPLS and GMPLS networks is that the security of the trusted zone not be compromised by interconnecting the MPLS/GMPLS core infrastructure with another provider's core (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users.
So, MPLS has been safe since it has been hidden away in the core, with no access to outsiders.
But this is about to change. The IETF MPLS WG recently elevated to working group status a document entitled Seamless MPLS Architecture (draft-leymann-mpls-seamless-mpls). This document proposes extending MPLS from the core into access networks, and seamlessly integrating the access domain into the core MPLS domain. In the words of the draft :
The motivation of Seamless MPLS is to provide an architecture which supports a wide variety of different services on a single MPLS platform fully integrating access, aggregation and core network. The architecture can be used for residential services, mobile backhaul, business services and supports fast reroute, redundancy and load balancing. Seamless MPLS provides the deployment of service creation points which can be virtually everywhere in the network.
…
With Seamless MPLS there are no technology boundaries and no topology boundaries for the services. Network (or region) boundaries are for scaling and manageability, and do not affect the service layer, since the Transport Pseudowire that carries packets from the AN to the SN doesn't care whether it takes two hops or twenty, nor how many region boundaries it needs to cross.
Seamless MPLS drops the boundaries between access, aggregation, and core networks. This may indeed simplify network management – but how are the security issues handled? The draft’s “Security Considerations” section states the following :
In a typical MPLS deployment the use of MPLS is limited to relatively small network consisting of core and edge nodes. Those nodes are under full control of the services provider and placed at locations where only authorized personal has access (this also includes physical access to the nodes). With the extensions of MPLS towards access and aggregation nodes not all nodes will be "locked away" in secure locations. Small access nodes like DSLAMs will be located in street cabinets, potentially offering access to the "interested researcher".
So far, so good. The draft authors understand the security problem they raise. But now for the punch line …
Nevertheless the unauthorized access to such in device SHOULD NOT impose any security risks to the MPLS infrastructure itself.
The term SHOULD NOT can be understood in two ways. Perhaps it is simply a statement that the authors believe that this placement of nodes in sites where they will be accessible to outsiders simply shouldn’t cause any problems, since no-one would think of attempting to exploit this vulnerability. Or perhaps this is a requirement for implementations, but not a strong MUST requirement, just a SHOULD requirement. In this case the authors are saying that perhaps in some cases it would be a good idea to do something about this, but only if there isn’t some other more important consideration.
But don’t panic - the draft authors add an additional sentence :
Seamless MPLS must be stable regarding attacks against access and aggregation nodes running MPLS.
Note that this requirement carries a non-normative must rather than a MUST. Also, seamless MPLS need not be impregnable to attacks, just stable. Network stability is defined in RFC 2360, the Guide for Internet Standards Writers. It means that the network does not take an infinite time to return to normal operation after some type of change. In this context, it apparently means that after a DoS attack is over, the network should return to normal functioning. Not a very strong requirement !
Can seamless MPLS be made safe (or at least as safe as present networks) ? Of course, but the effort would be substantial, requiring IETF to develop security mechanisms for non-IP traffic, something that has not been attempted to date. As the draft authors requested that the draft be accepted with all the rest of the security section marked “TBD”, fixing this lacuna does not seem to be very high on their list.
Y(J)S
Subscribe to:
Posts (Atom)