Philosophy (Installment 3 of a series)

In the previous installments I discussed the assimilation of communications and computation, the spectrum linking hardware and software, and how to virtualize communications functionalities. This installment is all about configurability and programmability.

I entitled this blog entry philosophy, since philosophy is literally the "love of knowledge", and generally deals with what we can learn about the world about us and how best to function in this world. Indeed epistemology is concerned with the nature of knowledge and ontology deals with the nature of existence itself.

Knowledge concerning the surrounding world is often indispensable for the proper functioning of communications devices. For example, a transmitter must know the frequency on which to transmit and the modulation scheme to use. An IP host needs to know the destination address to which to send packets, and the protocol to use. But how do communications devices acquire this knowledge?

Let’s start by envisioning a network element that functions out-of-the-box without any configuration options. We can say that such a network element is “zero-touch”. For example, fiber converters, hubs and repeaters, and even simple learning bridges are essentially zero-touch. Devices can be zero-touch simply because they are very limited in functionality. Or they can be flexible and sophisticated but still zero-touch because they are capable of learning all they need to know from their environment. Paradoxically zero-touch devices are either exceedingly dumb or exceedingly intelligent.

Many devices designed to be used by unsophisticated end-users, such as televisions and cellphones, hypothetically function without being set up. But this is obviously an over-simplification of the true situation. Modern televisions have remote controls that only the tech-savvy can handle (Is the set-top box connected to HDMI-1 or 2?  Which of the five supported aspect ratio options is best for HD?). Cellphone users are often stymied when they need to change time-zone or select a network. Configuring home WiFi routers is a task well beyond the capabilities of most mortals (Does my ISP use EoPPP, or L2TP or PPTP? Should my WiFi security be based on WPA or WPA2 with LEAP or PEAP? How does one set up port blocking? What exactly is an 802.11 beacon anyway?)

Early Ethernet switches were essentially zero-touch; they learned everything they needed to know by conversing with each other; when they didn’t know how to handle a frame they simply flooded it and observed the consequences. But then along came VLANs and one needed to configure which VIDs were to be admitted/emitted for each port (or to dictate “admit all”) as well as the default VLAN identifier for untagged frames. And the situation has gotten a lot worse since then. Ethernet OAM requires defining and configuring MEPs and MIPs, MEF services bring with them a complex set of bundling and bandwidth profile parameters, configuring 1X authentication can be a nightmare even for experts, and a PhD may be insufficient qualifications to correctly set up multicast. And this is before MEF’s new bandwidth sharing feature!

Routers rely on a strong standardized control plane, and should thus be much simpler to set up, right ?  Ever heard of Cisco CareerCertifications? There are five levels of certification (Entry, Associate, Professional, Expert, and Architect) along with targeted certifications for in seven different subject areas (Routing and Switching, Design, Network Security, Service Provider, Storage Networking, Voice, and Wireless). All that just to configure a router…

So we have communications devices that should be zero-touch, but in practice may require extensive configuration. This configuration may be manual and local (historically via a textual “CLI” interface but more recently via a GUI), or may be network-wide via a sophisticated network management system (NMS).

Of course, if configuration is so complex, you may be wondering why manufacturers can’t simply pre-configure their network elements so that the user can just turn them on and use them. Unfortunately, this is rarely, if ever, possible, due to the dynamic environments in which network elements are required to function.

If we want things to stay as they are, things will have to change.
 - Giuseppe Tomasi di Lampedusa (in The Leopard)

So we have seen zero-touch devices, and those that require basic configuration. The second step on the road towards full programmability is to enable a single device to combine the capabilities of multiple conventional devices, and then to configure it to function as any or all of these devices. For example, we could embed the functionalities of a L2 switch, a L3 router, and a L4 NAT in a single box, and then select whichever functionality needed in a particular instance. We could even opt to simultaneously activate many functionalities, provided that they are performed in the appropriate order.

This second step is precisely what an OpenFlow switch offers. A single device can match L2 header fields (SA, DA, EtherType, VLAN ID, VLAN priority), or L3 header fields (SA, DA, protocol number, DSCP, ECN), or L4 header fields (source and destination ports) and perhaps MPLS header fields (label, S-bit), and any combination thereof. However, in reality OpenFlow is more limited than just implied, in that the matching criterion is constrained to be exact match with bitmasks. A true combined L2-L4 device would be able to perform longest prefix match and port range match; but these limitations can be overcome at the expense of replicating flows.

A short digression (well, rant) is now in order. While such a combined device is advantageous in that it saves shelf space, power, and inventory carrying costs, it suffers from a major drawback. In today’s world of distinct devices, each device processes only that part of the packet for which it is intended, with the hardware limitation imposing opaqueness to the rest of the packet. Thus layering enforces intrinsic scoping which not only indicates clean design (similar to data abstraction in software) but also secures business interests. Once a single device can observe, act upon, and modify arbitrary fields, the ensuing layer violations can wreak havoc with service provision. Client layers could compel server layers to incorrectly forward packets or could hide traffic from billing systems. Lower layers could divert traffic to hostile destinations, or modify messages in transit. And such mayhem is not necessarily due to deliberate hacking, it will necessarily arise from simple errors in configuration. It is somewhat surprising that such flaunting of clean layering is proposed by academics in the name of data abstraction. Rant over.

The third step on the road to full programmability is a device consisting of lego blocks of useful functionalities. One could imagine a farm of general matchers (exact match, range match, regular expression match), a collection of rewrite modules, and a set of forwarding engines, all of which could be flexibly interconnected. Such a device can provide true DPI, as compared to the relatively shallow packet inspection of the previous step. Many network processors and some IDS systems are designed according to this philosophy.

At the far end of the spectrum sits the general purpose computer. Reminiscent of the zero-touch communications device with which we started, it too is supposed to function out-of-the-box. However, this functioning is limited (e.g., displaying a desktop). We purchase a computer entirely due to our expectation that it to be completely reprogrammed to perform any task, (well, at last if it has the required interfaces to the outside world – it can’t make coffee if it doesn’t have access to water and coffee grinds). In fact, once purchased we tend to forget about the computer (or smartphone) altogether. It becomes merely a platform for hosting applications, which are the products in which we are really interested.

The general purpose CPU is truly stronger than even the lego block model in that it can perform arbitrary calculations on arbitrary fields and make arbitrary forwarding decisions. For example, we could program a CPU to multiply the MAC source address by the IP destination address, xor the result with the last 10 bytes in the packet, take the hyperbolic sine of this, quantize to two bits, and use this result to forward to one of four output ports. Presumably this generality could also be used for something even more useful.

In the Apology, Plato tells how the Delphic Oracle declares that no-one is wiser than Socrates. Socrates, believing the oracle but knowing that he was ignorant of knowledge, goes out to discover what the oracle meant. He visits people he initially believes to possess wisdom - politicians, poets, and craftsman. After failing to uncover true wisdom in any of these, he comes to the conclusion that whatever wisdom he has derives from his knowledge that he knows nothing.

Truly a zero-touch philosophy!

Y(J)S

 

"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

DNSSEC - Internet root signed

IP addresses (even 4-byte IPv4 ones), are generally not easy to remember, which is why humans prefer to type domain names into their browser address window, even if they are longer. It is job of the Domain Name System (DNS) to translate the domain name into the correct IP address, which is placed in the IP header and enables proper forwarding.

The DNS works recursively in the following way. When my application (for instance, my browser) needs the IP address for some domain name, it queries the operating system’s DNS resolver. If the resolver already knows the IP address (for example, it is preconfigured, or that domain name has been recently looked up and is cached) it returns it to the application. If not, the resolver will query a DNS server, that has been configured or found using DHCP. If this server knows the IP address (i.e., it is cached there), it returns it in an “A record” (or an “AAAA record” for IPv6 addresses); otherwise it recursively queries until it finds a server that has the required “A record”. It may eventually get to the authoritative DNS server for the domain in question; that is, the name server that didn’t learn the IP address from another name server, but was configured with it.

This system is hierarchical and distributed and thus very scalable, but is not very secure. The archetypical attack is DNS cache poisoning, which is carried out by impersonating a name server that knows the desired IP address, and causing a name server closer to the resolver to cache the incorrect result. When queried the attacker’s IP address is returned to the user who then browses to a malicious site where it is tricked into accepting fallacious content or infected with viruses to be exploited later.

DNSSEC (Domain Name System Security Extensions) adds source authentication and integrity checking to the DSN system in a backwards compatible way. In DNSSEC the DNS responses are cryptographically signed with public key signatures, and thus can’t be forged. This thwarts cache poisoning exploits. In addition, DNSSEC can also be used to protect non-DNS data, such as “CERT records” that can be used to authenticate emails.

DNSSEC is described in RFCs 4033, 4034, and 4035 from 2005, but the root zone of the Internet was only signed in July, 2010. This major milestone was celebrated last week at the Wednesday IETF-78 plenary with glasses of champagne and the handing out of stickers declaring IETF – DNSSEC – SIGNED.

Y(J)S