Verify my service chain!

How do you prove that all traffic that is supposed to go through the service chain you specified actually made it through the service chain?

This blog was written by Frank Brockners, Sashank Dara, and Shwetha Bhandari.

Service function chaining is used in many networks today. The evolution towards NFV, combined with new technologies such as Segment Routing (SR) or Network Service Header (NSH) makes service chaining easier to deploy and operate – and thus even more popular. Unfortunately there is still one hard question left that management or security departments tend to ask: Can you please prove to me that all traffic that was meant to traverse a specific service chain really followed that path?

Service chain verification is here to help: By adding some meta-data to our traffic, we can now provide a packet by packet proof of the actual path followed. The meta-data can either be carried independently from the service chaining technology used (as part of in-band OAM information) or included in an NSH or SR header.

Service chain (or more generally packet path) verification, resembles what is often done for race control or orienteering runs: A group of people have to follow a specific route. Check points along the route are used to verify that participants actually followed the correct course. This verification can be done in different ways: Either one creates the route in a way that there is only a single path possible (e.g. there is only a single bridge across a river), a track marshal logs the participants’ numbers or the participants carry a pass that is checked and stamped at all check points. Only those participants proven to have passed all check points by presenting all stamps at the finish qualify as course completers.

Figure 1: Service Chain Verification.

Current approach to verification: Service chain (or packet path) verification isn’t that different. The security departments require a proof that packets of certain applications were processed according to the company’s security policy: If a packet flow is supposed to go through a series of service functions or network devices such as routers or switches, it has to be proven that all packets of the flow actually went through all components of the appropriate service chain according to the company’s policy. In case the packets of a particular flow weren’t appropriately processed, then a domain edge device would be required to identify the specific policy violation and take corresponding actions (e.g. drop or redirect the packet, send an alert, etc.). In most of today’s deployments we typically use the approach of a “track marshal” or “only a single path is possible” to prove that a service chain is fully functional: Service appliances and network forwarding are situated in different trust domains. “Hand-off-points” are then defined between these trust domains (i.e. physical interfaces – the equivalent of the single bridge across the river). In other terms, in the “network forwarding domain” devices are connected in a way that traffic is delivered to the ingress interface of a service appliance and received back from an egress interface of another service appliance. This “wiring” is verified (often using intrusion detection systems or similar) and trusted.

Evolving applications to NFV (and modern service chaining concepts using virtual overlays such as LISP, NSH, etc.) blurs the line between the different trust domains, because the demarcation or hand-off-points are no longer clearly defined physical interfaces, but are virtual interfaces. These factors mean that several organizations actually prohibit mixing different trust layers within the same device”. In result NFV in its current form becomes a none-starter for these companies. For an NFV scenario a different service chain traversal proof is clearly required.

Per packet verification as the evolution: Rather than the indirect proof (using a track marshal or through direct configuration/wiring) let’s use a capability like that used in orienteering runs (where participants carry a pass stamped at every check point) Additional meta-data is added to all packets that traverse any service chain component. The added meta-data allows a verifying node (typically an egress node) to check whether a packet traversed the service chain correctly. Security mechanisms are applied to the meta-data to protect against incorrect or misuse (i.e. configuration mistakes, people playing tricks with routing, capturing, spoofing and replaying packets).

The meta-data is actually secured through the use of cryptographic keys. Discrete service functions retrieve their keys from a controller over a secure channel. Depending on whether the service functions support hardware-assisted encryption, different mechanisms can be used:

• For general deployments, i.e. those where hardware-assisted encryption might not be available, Shamir’s Secret Sharing method can be employed. A single secret is associated with a particular service chain. Shares of the single secret are distributed from the controller to each of the service functions. Service functions use their share of the secret to update the metadata in the packet. Only a verifying node has access to the complete secret that it can use to validate the correctness of the received meta-data thereby confirming that a packet visited all intended service functions in the chain. The secret combined with unique per packet data aid in preventing service chains being bypassed (either due to misconfiguration, defect in software implementation or deliberate attacks such as packet replay). The implementation can be done without impacting forwarding performance as it involves simple arithmetic operations per packet.

Figure 2: Shamir’s secret sharing based verification is comparable to the operation of a prism.

• For deployments that offer hardware-assisted encryption, an alternate method which leverages a set of secret keys can be used: A service is described by a set of secrets, where each secret is associated with a service function. Service functions encrypt portions of the meta-data as part of their packet processing. Only the verifying node has access to all secrets. To verify whether a packet correctly traversed the service chain, the verifying node re-encrypts the meta-data received as part of the packet using all the secrets. Encryption without performance degradation requires hardware assistance and so this approach mostly applies to deployments where all the service functions have hardware-assisted encryption.

Placement of the meta-data for service chain validation depends on the service chaining technology used. One novel approach can be to carry the meta-data as part of the “in-band OAM” IPv6 extension header or as a new NSH MD-type 1 if the network service header is used for service chaining or as part of Segment Routing extension header.

Does this sound of interest to you the reader? This is the second blog in the series on “in-band OAM for IPv6 (iOAM6)”. Service chain and path verification is a key capability that iOAM6 offers. iOAM6 is a project which is currently in “proof-of-concept” state at Cisco; Steve Simlo is the IPv6 product manager and covers iOAM6. If you are attending CiscoLive in San Diego this June, you could arrange a meeting with myself and Steve and also attend the breakout session “BRKRST-2606: Always on visibility: In-band OAM for IPv6” or visit the DevNet Zone for a live demo of “service chain verification”.