Kabir, Kantola, and Llorente Santos
206
The value CETP + cesid indicates the availability of the CETP service. The NAPTR
response carries the publicly reachable address called Routing Locator (RLOC) for con‑
necting to the remote CES, in this example indicated by “ip = 182.3.2.55”. The response
can also carry other RLOC types, such as IPv6, and it can be used in conjunction with
fields, such as port numbers for identifying the exact location of the CETP service in the
remote network. The CETP service can be available in future on top of other protocols,
such as TLS/TCP, HIP, etc. The alias field allows the use of private transit links instead
of the public links. A NAPTR response may also contain a CES identifier in “cesid:1 = cesb.
ces” for routability checks.
The NAPTR records could be hosted by third‐party DNS servers or cached by
intermediate DNS proxies. However, if the CES node has the authority over the DNS
leaf, that is, the network that it serves, this would improve the CES functionality and
administration. For hosts, the decoupling of endpoint identifiers from routing loca‑
tors means that an IP address can no longer be used to identify a host. Instead, CES
leverages the concept of proxy‐address to represent the remote hosts in its local net‑
work. These proxy‐addresses are allocated from the IPv4 private address space [12]
or the IPv6 Unique Local Address (ULA) [13], depending on the addressing of
the host.
9.3.2 CETP Policy‐based Communication
The CETP protocol has been developed to convey signalling and data across CES nodes.
The scope of signalling is exclusively CES related and is used to exchange:
a) network‐level CES policies for establishing trust between CES networks; and
b) individual host or application policies, for establishing data connection between two
hosts across their CES nodes.
The information exchanged in the signalling depends on these policies. The use of
CES in mobile networks allows the policies that can scale up to individual hosts, services
or applications and are not tightly coupled to the physical resources.
The data plane only carries the user‐generated data, which is tunnelled using CETP
session identifiers. The session identifiers are negotiated during the CETP signalling
phase and are used to distinguish between different user connections on the data plane.
Moreover, the negotiation of data RLOCs during signalling makes it possible to carry
user data on different links than the signalling, to achieve a higher level of assurance and
improved heuristics of the algorithms.
A CETP packet starts with a mandatory 4‐byte header that identifies the protocol
version and CETP header length. This is followed by source and destination session tags
(or identifiers), and optional signalling or payload information. CETP signalling carries
the host or network policies encoded in a flexible Type‐Length‐Value (TLVs) format.
These TLV‐encoded policy elements are classified according to the Type field, which
can be further decomposed into operation, group and code fields. A list of currently
supported TLV elements is classified as per the group and code field and is presented
in Table 9.1.
206
The value CETP + cesid indicates the availability of the CETP service. The NAPTR
response carries the publicly reachable address called Routing Locator (RLOC) for con‑
necting to the remote CES, in this example indicated by “ip = 182.3.2.55”. The response
can also carry other RLOC types, such as IPv6, and it can be used in conjunction with
fields, such as port numbers for identifying the exact location of the CETP service in the
remote network. The CETP service can be available in future on top of other protocols,
such as TLS/TCP, HIP, etc. The alias field allows the use of private transit links instead
of the public links. A NAPTR response may also contain a CES identifier in “cesid:1 = cesb.
ces” for routability checks.
The NAPTR records could be hosted by third‐party DNS servers or cached by
intermediate DNS proxies. However, if the CES node has the authority over the DNS
leaf, that is, the network that it serves, this would improve the CES functionality and
administration. For hosts, the decoupling of endpoint identifiers from routing loca‑
tors means that an IP address can no longer be used to identify a host. Instead, CES
leverages the concept of proxy‐address to represent the remote hosts in its local net‑
work. These proxy‐addresses are allocated from the IPv4 private address space [12]
or the IPv6 Unique Local Address (ULA) [13], depending on the addressing of
the host.
9.3.2 CETP Policy‐based Communication
The CETP protocol has been developed to convey signalling and data across CES nodes.
The scope of signalling is exclusively CES related and is used to exchange:
a) network‐level CES policies for establishing trust between CES networks; and
b) individual host or application policies, for establishing data connection between two
hosts across their CES nodes.
The information exchanged in the signalling depends on these policies. The use of
CES in mobile networks allows the policies that can scale up to individual hosts, services
or applications and are not tightly coupled to the physical resources.
The data plane only carries the user‐generated data, which is tunnelled using CETP
session identifiers. The session identifiers are negotiated during the CETP signalling
phase and are used to distinguish between different user connections on the data plane.
Moreover, the negotiation of data RLOCs during signalling makes it possible to carry
user data on different links than the signalling, to achieve a higher level of assurance and
improved heuristics of the algorithms.
A CETP packet starts with a mandatory 4‐byte header that identifies the protocol
version and CETP header length. This is followed by source and destination session tags
(or identifiers), and optional signalling or payload information. CETP signalling carries
the host or network policies encoded in a flexible Type‐Length‐Value (TLVs) format.
These TLV‐encoded policy elements are classified according to the Type field, which
can be further decomposed into operation, group and code fields. A list of currently
supported TLV elements is classified as per the group and code field and is presented
in Table 9.1.