IETF wants packets to prove where they've been, to improve trust
Virtualisation is creating traffic handoffs that don't depend on physical ports
Virtualization changes everything – and in the case of the routers that keep the Internet working, it's not always in a good way.
Over the years, the IETF has accepted a variety of proposals that let network admins stipulate where their packets will go, under working groups like Internet Traffic Engineering and Service Function Chaining.
According to a group from Cisco, Comcast, Marvell Semiconductor, and JP Morgan Chase, however, the rise of virtualisation makes it increasingly difficult to know that packets traverse the nodes they should.
In this Internet-Draft, rated experimental, the researchers propose what they call a “Proof of Transit” that would “securely verify whether, within a given path, all packets traversed all the nodes that they are supposed to visit”.
The problem, they wrote, is that current approaches assume a physical hand-off between different trust domains – to take an Internet exchange as one example, the hand-off is between ports in boxes owned by different service providers.
“The proof that a packet traversed a particular path or service chain is typically delivered in an indirect way: Service appliances and network forwarding are in different trust domains”, the Draft explained.
Once Provider A's ingress port is connected to Provider B's egress port, that “wiring” is the basis of a trusted connection.
Virtualization doesn't fit comfortably with these assumptions, the Draft explained: “Network Function Virtualization (NFV) and modern service chaining concepts (using technologies such as Locator/ID Separation Protocol (LISP), Network Service Header (NSH), Segment Routing (SR), etc.) blurs the line between the different trust domains”, they wrote.
Such scenarios need a new type of proof of transit, and that's what's offered in the draft.
Packets should carry a proof-of-transit (POT) as a small amount of their data, the Draft suggests, that can be updated at each node defined as the path.
Security is, naturally enough, critical to such a scheme, to make sure malicious networks don't provide counterfeit the information provided by their nodes. The Proof-of-Transit draft offers two choices for verification: either a set of secret keys, or a set of shares of a single secret.
“Nodes on the path retrieve their individual keys or shares of a key (using for e.g., Shamir's Secret Sharing scheme) from a central controller”, the Draft states.
The complete key (or key set) is known only to the controller and the “ultimate node on a path” acting as a verifier. Nodes between the ends of the path add their own part of the key, and the verifier, which receives them all, can validate if the packet traversed the path correctly.
The secret sharing scheme referenced in the Draft, Shamir's Secret Sharing, was devised by the “S” in RSA, Adi Shamir, and is explained here. ®