| Internet-Draft | Secure Vector Routing (SVR) | October 2021 |
| Menon, et al. | Expires 4 April 2022 | [Page] |
This document describes Secure Vector Routing (SVR). Secure Vectors contain application layer metadata used for authentication and communicating network intent between data routers. The metadata is extensible, and could be used to transmit information, network routes, security policies, and quality policies securely across network boundaries. Boundaries include those formed by private network RFC1918 networks with the IPv4 public internet, and the IPv6 public internet.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 April 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
There exists a need to extend network intent across multiple IP networks and paths to provide an end-to-end experience. Selection of specific paths and their attributes is a key intent. There is also a need for applications to communicate their intent to networks. This need is increasing as workloads move to public cloud and the numbers of cloud locations increase. The standard practice today is to use an overlay network of tunnels to create a virtual network. SVR is being proposed as an alternative to using tunnels, which simplifies the network by virtue of having only one network to manage and securely transport traffic with encryption and authentication; also, the absence of tunneling overhead reduces bandwidth. Since SVR specifies intent abstractly, it also has the capability to interwork policies between different networks and address spaces.¶
Most networks are deployed with a virtual private network (VPN) across IP backbone facilities. VPNs have the significant disadvantage of carrying additional payload on top of the actual packet thereby leading to IP fragmentation as well as reduced bandwidth. In this document, SVR is being proposed as a new technique which is session aware and does not have the overhead of IP tunnels.¶
A Secure Vector Route (SVR) describes a network intent and shares this intent in the form of metadata with a routing peer. The intent to a peer router is conveyed by means of a cookie, often referred to as first packet metadata, which is placed on the first packet that is targeted towards the peer. SVR is session aware on every router and sets up a biflow (forward and reverse flows) based on the intent. Once the session is set up, the cookie is not sent for the subsequent packets.¶
+---------+ +---------+
+----+ | Edge | (-------------) | Edge | +----+
|CPE |--| Router |--( IP Backbone )---| Router |--|CPE |
+----+ | | (-------------) | | +----+
+---------+ +---------+
<-------SVR ------->
This intent must include:¶
Service(s): This is a textual description of what server(s) can be accessed with this intent. Examples include Zoom, or Office365/Outlook. Although outside the scope of this document, these could be defined with any known technique, including URLs, IP address(es) protocol(s) and port(s), CIDR block(s), etc. Having a single text name to describe a network destination makes applying network intent easier. This Service name can be used to define all other attributes of network intent including:¶
These additional attributes are outside the scope of this protocol as they are locally defined and associated locally to the specific Service.¶
When performing HMAC signatures, or payload encryption, key management is also outside the scope of this document. Standard IKEv2 techniques could be applied, or integration with authentication systems may be appropriate.¶
A Secure Vector Route can be described as a Qualified Service Name (QSN). This is shorthand for a human understanding of a specific network intent definition. This shorthand is used in use case examples, but is not part of the specific protocol.¶
QSN://[subtenant.]tenant.authority/service/subservice
¶
The QSN conforms with the definition of a URL. The QSN describes the Direction, Tenant, and Service of an SVR. The QSN introduces the concept of a naming authority, which controls the namespace for subtenants, tenants, services, and subservices. Examples of QSNs include the following:¶
QSN://engineering.juniper/github/project
QSN://engineering.acme/github
¶
These examples indicate that juniper and acme are different authorities, and can each completely describe a QSN without defining overlapping intents in any way. The first example is a name for the intent definition for engineering at juniper to access github for a specific project. In the second case, engineering at acme can access any resources defined as github. QSNs will be used in this document and are useful in describing a high-level intent.¶
The SVR metadata must be inserted into existing packets directly after the L4 header, even if the resulting increase in packet size would cause the packet to require fragmentation. The metadata must be in the very first packet of a new session (TCP or UDP bidirectional flow) to have any role in path selection or security. Metadata may be sent in any subsequent packet to change/update the networking intent. The metadata is inserted into the payload portion of a packet to guarantee it makes it unchanged through the network. Packet lengths and checksums must be adjusted accordingly, although adjusting TCP sequence numbers is not necessary.¶
A SVR Peer is any client, server, or network element that can understand and participate in SVR. Having pre-shared cryptographic keys, and the ability to authenticate and decrypt metadata is a prerequisite to being a peer. Peers do not have to be directly adjacent, but reachable via IP networking, even across network boundaries. Examples of peers include:¶
A branch router and a data center edge router:¶
+-----------+ +-----------+
| | | |
| Branch | ---------------------------->| Datacenter|
| Router | Secure Vector Routing(SVR) | Router |
| | | |
+-----------+ +-----------+
¶
A client desktop computer and a nearby router:¶
+-----------+
+-----------+ | |
| Computer | ---------------------------->| Router |
+-----------+ Secure Vector Routing(SVR) | |
+-----------+
¶
A WIFI AP and an edge router:¶
+-----------+
+-----------+ | |
| Wifi AP | ---------------------------->| Router |
+-----------+ Secure Vector Routing(SVR) | |
+-----------+
¶
A data center edge router and a VPC based router in a public cloud:¶
+-----------+ +-----------+
| | | |
| Edge | ---------------------------->| Cloud VPC |
| Router | Secure Vector Routing(SVR) | |
| | | |
+-----------+ +-----------+
¶
SVR Peers may have many different possible pathways between them. Each path must be discovered, and its service state should be known prior to sending metadata. Techniques such as BFD (RFC 5580) could be used to determine path availability. Each of these individual paths between peers is called a "peer path." Secure Vector routes are always defined and used between peers and can support session resiliency across multiple paths.¶
Peer paths are defined by their IP addresses or hostnames. Routers with multiple interfaces may have multiple peer paths to a next hop router. The IP addresses routers use on their interfaces are also referred to as waypoints. Every peer path can be defined by a pair of waypoint addresses. To avoid confusion when branch or edge devices obtain new IP addresses dynamically, these peer paths are assigned a hostname which is used instead. The named pathway and associated keys(ip-address/hostname and peer name) are provisioned and presumed available in this specification. Details of this provisioning are outside the scope of this document.¶
The protocol utilizes the concept of direction. Direction is either forward or reverse; it is not tied to network topology, but rather the direction of session establishment. For TCP, the forward direction is always the client side towards the server side. For UDP, the forward direction is from the sender of the first packet. Reverse is the opposite direction.¶
These directions can be used to qualify a path between a pair of SVR Peers, the ingress and the egress (forward is from ingress to egress); or to qualify metadata (forward metadata is inserted by the ingress).¶
To ensure the metadata is received and understood between peers, a handshake is performed. A router that supports SVR peer paths inserts metadata for each packet flow in the following circumstances:¶
These two comprise what is known as the "metadata handshake" -- that is, the initiating router includes metadata in all packets it sends to the recipient router until it receives a reverse packet with metadata from that recipient. Likewise, the recipient continues to send metadata to the initiating router until it receives a packet without metadata. This is how two routers acknowledge receipt of metadata from their counterparts: the absence of metadata in a packet indicates that it has received metadata from its counterpart.¶
Firewalls and middleboxes that sit along a peer path may not tolerate TCP SYN messages with data in the payload, or may verify sequence numbers in TCP streams (which are invalidated due to the inclusion of SVR metadata). The two devices that represent the peer path endpoints may determine through testing if there is a firewall, NAT, or other active middlebox between the two routers. Procedures for this (like STUN/TURN/ICE) are well known, and not included in this document. If a middlebox is detected, the packets can be UDP-transformed ie; the protocol byte can be changed from TCP to UDP by the transmitting router and restored to TCP by the receiving router for packets flowing in both directions. The sequence number of the TCP packet will be copied to the TCP checksum location as it will be overwritten by the UDP header. The original protocol in use is part of the context in the metadata and can be restored by the receiving peer.¶
To prevent breaking any applications, there must be a 100% guarantee that metadata inserted by a participating SVR device is removed prior to the consumption of the data by the application service. If the client and server support metadata, then the network intent can be sent end-to-end. When a mid-stream packet router wants to insert SVR metadata, it must guarantee that the packet is directed to a next hop device that will understand and remove the metadata.¶
To guarantee that the packet will go to a specific device, the destination address for the packet is changed to the waypoint address of the next hop. Because the original addresses are stored in the context field, they can be recovered if needed. This is similar to IPv6 segment routing or a LISP RLOC with the exception that the original addresses are stored in metadata within the payload portion of the packet, and not the IP Header.¶
To communicate to the next hop the origin of the packet and to define and open a return path, the source address of the packet is NATted to the interface of the source router. This is called a source waypoint address. This provides a return path and can be used to guarantee symmetric flows if desired. Once again, the original addresses are state information that the source router must maintain.¶
To avoid sharing a hash with all traffic, and to make sessions completely independent, the source port and destination port can be assigned any values that are unique by the source router. When there are no NATs between the two router interfaces, this permits 2^32 (4,294,967,296) different unique sessions on a peer path. If there are source NATs, this will be reduced to 2^16 (65,536) different unique sessions. Ports can be reassigned if not in active use. It is also possible that middle boxes will limit what destination ports are permissible, reducing the number of possibilities. The range of ports that can be used could be discovered at run time by testing a peer path, provisioned, or both.¶
Note: The ingress SVR peer (client side) assigns both source and destination ports. The ingress side always chooses even ports for local (source port) and odd ports for remote(destination port) This provides total uniqueness between any two peers, with no negotiation or collision possibilities. Think of the two ports as a Sessions Identification Tag. Even if a session traveling in the opposite direction was allocated the same exact ports, because the source address and destination addresses would be swapped, the 5 tuples on the wire remain unique.¶
Each participant (peer) in secure vector routing must maintain state for every active session. This includes the full set of original addresses and translations required. This allows participants to stop sending metadata once it has been received by the peer. Should one side lose state information, it can notify the other that it must send metadata to restore a session. Typically a path change will trigger metadata to be turned on for the subsequent forward packets so that the new session state including the waypoints can be maintained by the next hop router.¶
Each SVR router (peer) must statefully remember the source address that a session with metadata was received on. This may not be the same address the router sent a packet from due to a NAT or Firewall in the pathway. Routers use provisioned waypoint addresses, but statefully record and store the actual waypoint addresses.¶
The format of metadata has both Header attributes as well as Payload attributes. Header attributes are always guaranteed to be unencrypted. These headers may be inspected by intermediate network elements but can't be changed. Payload attributes optionally can be encrypted by the sender. The pre-existing security association and key sharing is outside the scope of this document. Each attribute listed below will indicate whether it is a header attribute (unencrypted) or payload attribute (optionally encrypted). There are no attributes that can exist in both sections.¶
The metadata header is shown below. A well-known "cookie" (0x4c48dbc6ddf6670c in network byte order or 0x0c67f6ddc6db484c in host byte order) is built into the header which is used in concert with contextual awareness of the packet itself to determine the presence of metadata within a packet. This is an eight-byte pattern that immediately follows the L4 header and is an indicator to a receiving router that a packet contains metadata. NOTE: Because packets are not normally directed to a routers interface, all packets arriving on a waypoint should include metadata or they will be dropped.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Header Length | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header TLVs ... | Payload TLVs ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Given that no byte sequence is truly unique in the payload of a packet, in the scenario where the original payload after the L4 header contained the same byte sequence as the cookie, false positive logic is enacted on the packet. If the metadata signature can't verify that the metadata is valid, then a false positive metadata header is added to the packet to indicate that the first eight bytes of the payload matches the cookie. The structure of a false positive metadata packet is one which has a metadata header length that is the same as the base header size as well as having zero payload length. The receiving side of a packet with false positive metadata will strip out the metadata header if the next hop of the packet is not expecting a metadata header.¶
In the scenario where a router receives a false positive metadata header but intends to add metadata to the packet, the false positive metadata header is modified to contain the newly added attributes. Once attributes are added, the metadata header is no longer considered to be false positive.¶
Header attributes are unencrypted and not associated with any one specific session, and do not have a forward or reverse direction. These are tied instead to the router peer path itself. The metadata header contains a 12-bit field associated with the header length of the metadata header. The field represents the overall length of the header. Its base value is 0xC which is the initial length of the metadata header.¶
The value 0xC comes from:¶
64 bits Cookie Length
4 bits Metadata Version
12 bits Header Length
+ 16 bits Payload Length
--------------------------
96 bits = 12 bytes decimal = 0xC hex
¶
Any value greater than 0xC would indicate that there are optional attributes associated with this metadata header which are guaranteed to be unencrypted.¶
An example of an optional attribute which would reside in the guaranteed unencrypted section of metadata would be per-packet fabric fragment attribute. This attribute is not associated with any session or encryption schema and as such must not be encrypted.¶
The metadata header contains a two-byte payload length field which is associated with attributes that can be encrypted.¶
Each metadata payload attribute may be valid in the forward direction, the reverse direction, or both. If not valid, it is ignored quietly by the receiving side.¶
When a packet is fragmented to insert metadata, a new fragmentation mechanism must be added to prevent fragmentation attacks and to support reassembly (which requires protocol and port information). If a packet is received that IS a fragment, and it must transit through a metadata signaled pathway, it must also have this metadata attached to properly bind the fragment with the correct session.¶
All fragments will have a metadata header and the fragment TLV added to the guaranteed unencrypted portion of the metadata header. If the original packet already has a metadata header on it, the fragment TLV will be added to it.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original ID |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Largest Seen Fragment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field used for identifying fragment attributes. They are (in order, from most significant to least significant):¶
A versioning identifier used to determine which security key version should be used when handling features dealing with security and authenticity of a packet.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 16 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An indication that forward metadata should be disabled. This is sent in the reverse metadata to acknowledge receipt of the metadata. This is the second part of the metadata handshake.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 18 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: This type does not contain any value as its existence in metadata indicates a true value.¶
The IP address of the originating packet on the wire. This is sent by the source to the destination because there may be a NAT between the two routers. By recognizing the actual source packet on the wire, and comparing it with this field, a router can detect a NAT is present.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 20 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IP address of the originating packet. This is sent by the source to the destination because there may be a NAT between the two routers. By recognizing the actual source packet on the wire, and comparing it with this field, a router can detect a NAT is present.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 21 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Used for TCP session optimization between peers. Allows sending side in long latency situations to queue packets and retransmit them to optimize TCP traffic.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 23 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SACK Seq. No. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Left Edge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Right Edge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The SVR Protocol Message is a force drop message that is used as an out-of-band signaling mechanism between 128T routers. These are messages that are internally generated and not intended to be forwarded through the router to another destination. Any sessions utilizing the 5 tuples defined by the received packet with metadata may be acted upon based on the drop reason.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 24 | Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Drop Reason | +-+-+-+-+-+-+-+-+
Reason why this packet should be dropped.¶
Inline flow performance metrics to compute jitter, latency and loss per service, per path, per traffic class.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 26 | Length = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Co | Transmit TimeValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Co | Received TimeValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Previous Rx Color Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A modify operation on an existing session, which diverts the packet to the service area for additional treatment and processing. This forces an "inline" session modify instead of allocating new waypoints to cause the same behavior.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 28 | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|D|res| sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload attributes are used for session establishment and can be encrypted to provide privacy. Encryption can be disabled for debugging.¶
The context contains a five-tuple associated with the original addresses, ports, and protocol of the packet. This is also known as the Forward Session Key.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length = 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | +-+-+-+-+-+-+-+-+
A five-tuple associated with the original addresses, ports, and protocol of the packet for IPv6.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length = 37 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | +-+-+-+-+-+-+-+-+
Five-tuple associated with the egress (router) addresses, ports, and protocol of the packet. Forward context and reverse context session keys are not guaranteed to be symmetrical due to functions which apply source NAT, destination NAT, or both to a packet before leaving the router.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length = 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | +-+-+-+-+-+-+-+-+
Five-tuple associated with the egress (router) addresses, ports, and protocol of the packet. Forward and reverse session keys are not guaranteed to be symmetrical due to functions which apply source NAT, destination NAT, or both to a packet before leaving the router.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length = 37 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | +-+-+-+-+-+-+-+-+
Unique identifier of a session. This is assigned by the peer that is initiating a session. Once assigned, it is maintained through all participating routers end-to-end.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + UUID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alphanumeric ASCII string which dictates what tenancy the session belongs to.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alphanumeric string which dictates what service the session belongs to. This attribute must be present in all forward metadata packets.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Indicates if the session is having its payload encrypted. This enables payload encryption with tenant specific attributes and keys. Details of key management and encryption types are outside the scope of this standard.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: This type does not contain any value as its existence in metadata indicates a value.¶
Indicates if the packet in question is a TCP SYN packet. Due to the potential that this packet could have had its TCP header transformed to UDP temporarily, the flags in the TCP header may not be accessible.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: This type does not contain any value as its existence in metadata indicates a value.¶
An alphanumeric string which dictates which source router the packet is originating from. This attribute may be present in all forward metadata packets if needed.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 14 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alphanumeric string which dictates what security policy to be used for encrypting metadata when sending reverse packets back to this router. This attribute is optional.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 15 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alphanumeric string which dictates which destination router the packet is sent to. This attribute may be present if needed.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 17 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alphanumeric string which dictates which router path has been chosen for a packet. This name can be the hostname or IP address of the egress interface of the originating router. Any two routers may have multiple pathways between them. This enables association of policies with specific paths.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 19 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alphanumeric string which dictates which router path has been chosen for a packet. This name can be the hostname or IP address of the egress interface of the originating router. Any two routers may have multiple pathways between them. This enables association of policies with specific paths.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 25 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metadata can be inserted and used to share network intent between routers. Below are examples for specific use cases. The metadata is not limited to these use cases, these are just illustrative.¶
Before a client or router can send metadata to a next hop router or server, it must know apriori of the next hop router's existence (and interface IP Address or waypoint). The client or router must also have a routed path to the IP Address (as determined by L2 and L3 routing protocols). The mechanism to obtain the router's address is outside the scope of this document. This could be through configuration, a DNS lookup, a LISP like RLOC query, or through a registry service. Routing protocols can be used to share topology as needed to locate supporting routers, and to obtain and share cryptographic keys.¶
Client software that does not have access to routing layers can generate packets to test if the default route supports metadata by sending specially constructed packets to the default gateway.¶
If a router or client learns the IP address of a participating peer, it can then verify the path and performance by using BFD or other quality measurement techniques. Once connectivity is established (at L2, L3, and SVR), the peer path status and performance measurements can be measured. This measured criteria can be used to select which peer path to use. This is outside the scope of this document.¶
Testing path availability is outside the scope of this document. BFD is frequently used to verify that a path to a router is available. Lack of a metadata response when sending sessions to a router indicates that path is unavailable as well. Since routers are also running routing protocols, should the waypoint address become unreachable, the path is also declared down.¶
When a client or router detects that a new session is being established, metadata must be inserted into the first packet to communicate intent to a next hop router. Detecting a new session is protocol specific. For TCP, it's a new 5 Tuple packet (new flow) that is a SYN packet. For UDP, it's simply a new 5 Tuple packet not currently in use. These are easily detected because:¶
Because it is a flow miss, the router will forward the packet internally to a branch of code that will look up routes and insert metadata.¶
For illustrative purposes, assume that the packet is an engineer at Juniper Networks attempting to access a Zoom video conference service. The resulting QSN is: QSN://engineer.juniper/zoom.¶
Locally, the source IPv4 address for the engineer is 10.0.1.1. Engineers are assigned to vlan 10, and DNS resolves the Zoom address to be 3.208.72.109. When the packet arrives at the branch router with the name "Branch 1", the following steps will be performed:¶
The determination of a service is essential. With Zoom by example, the current published list of IP addresses, protocol, and ports include over 230 CIDR block ranges where the most common block is a /25. Describing network intent would be difficult using IP Addresses.¶
Once the tenant and service are known, the routing intent can be determined. The routing policies are checked, specifically:¶
Select a peer to send the session to:¶
Choose a peer path, and establish fast path rules for subsequent packets:¶
Once all of these local L2/L3 parameters are mapped to Tenant/Service routing intent, then metadata can be constructed an inserted into the first packet (for TCP A SYN Packet).¶
The metadata attributes that will be inserted includes:¶
When the first packet is sent, the sending side will include the same exact metadata on every packet until a packet in the opposite direction (reverse direction) arrives with metadata indicating a complete handshake. For TCP, the SYN packet contains metadata, and typically a SYN-ACK from the server side responds with metadata, and there is no further metadata inserted in a session.¶
Client ----> TCP SYN w/Metadata ----> Server
Server <---- TCP SYN-ACK w/Metadata <---- Server
¶
For UDP, metadata can be inserted in packets until there is a reverse flow packet.¶
The metadata is signed with an HMAC signature that is a defined number of bytes long. The signature used is defined by RFC2104. The HMAC signature is placed at the very end of the packet, extending the packet length by the number of bytes. The shared keys used for signing and verifying the authenticity of the packet are outside the scope of this document, but could be any well known and trusted key distribution scheme.¶
The metadata Payload Headers are encrypted utilizing AES256, with the initialization vector (IV) supplied directly after the encrypted data to guarantee the receiver can decrypt the information statelessly.¶
When a next hop router receives a packet directed to an interface the router owns that has a uniquely new 5 tuple, it can reasonably expect the packet (if not a routing protocol packet) contains metadata. By performing DPI on the received packet, the router can determine positively if metadata is present. If so, the metadata can be authenticated, decrypted, parsed for network intent, and removed. The packet is forwarded (possibly through a second SVR). When a first reverse packet is received for the session, the router will construct a block of metadata in the reverse direction. The purpose of this is:¶
The reverse metadata attributes that will be inserted include:¶
As soon as the initiating router gets confirmation that the next hop router understands the metadata, it can stop sending metadata. In the case of the TCP transport layer, this occurs with the 2nd packet of the session, first reverse packet, the TCP SYN-ACK response.¶
No metadata is sent upon normal session termination. The router can monitor the TCP state machine and have a guard timer after seeing a FIN/ACK or RST exchange. After the guard timer, the session can be removed from the system. If a new session arrives during this period (A TCP SYN), then it will cause immediate termination of the existing session. In addition, all protocols also have an associated inactivity timeout, after which the session gets terminated if no packets flow in either direction.¶
When there are multicast flows, or asymmetry, the sender must assume for TCP when the sequence number is advancing, that there is end-to-end communication, and one can stop sending metadata. For UDP asymmetry the sending router will send a maximum of 11 packets with metadata and if no reverse packets are seen, the receiving peer router will trigger a disable metadata packet to the originating router to turn off metadata for subsequent forward packets.¶
To change the pathway of a session between two routers, one simply reinserts the metadata described in section 3.2.1. but retains the same Session UUID. This will cause the upstream router to do the following:¶
When the sender of the metadata sees packets returning on the new interface, the old fast path entries can be removed.¶
HMAC signatures are mandatory for the packets that contain Metadata to guarantee the contents were not changed, and that the router sending it is known to the receiver. Any HMAC algorithm can be used, from SHA128, SHA256 or MD5, as long as both sides agree. HMAC is always performed on the layer 4 payload of the packet.¶
Optional HMAC signatures can be added to every packet. This prevents any mid-stream attempts to corrupt or impact sessions that are ongoing. The signature must include all of the packet after Layer 4, and include a current time of day to prevent replay attacks.¶
Both the sending and receiving routers must agree on these optional HMAC signatures, details of which are outside the scope of this document.¶
Payload encryption can use AES-CBC-128 or AES-CBC-256 ciphers which can be configured. Since these are block-ciphers, the payload should be divisible by 16. If the actual payload length is divisible by 16, then the last 16 bytes will be all 0s. If the actual payload is not divisible by 16, then the remaining data will be padded by 0's and the last byte will indicate the length.¶
Waypoint addresses could be addressed by any client at any time. IP Packets that arrive on the router's interface will be processed with the assumption that they MUST contain metadata OR be part of an existing established routing protocol.¶
Routers will only accept metadata from routers that they are provisioned to speak with. As such an ACL on incoming source addresses is limited to routers provisioned to communicate. All other packets are dropped.¶
When a packet is received the "cookie" in the metadata header is reviewed first. If the cookie isn't correct, the packet is dropped.¶
The HMAC signature is checked. If the signature validates, the packet is assumed good, and processing continues. If the HMAC fails, the packet is dropped.¶
These methods prevent distributed denial of service attacks on the waypoint addresses of routers.¶
The authors would like to thank Anya Yungelson, Scott McCulley, and Patrick MeLampy for their input into this document.¶