Kabir, Kantola, and Llorente Santos
210
the classical Internet weaknesses of address spoofing, unwanted traffic and DoS prior to
admitting a flow from the sender. CES provides the above mechanisms as policy‐
controlled features for network administrators, and gives different level of assurances
based on the configured mechanisms. We briefly describe these mechanisms that
minimize the risks to CES from Internet abuse:
● Proof‐of‐Work: is an effective method in many anti‐spamming and anti‐flooding
proposals, since it makes it difficult for the sender to flood the victim with a large
number of flows. The use of this mechanism in network‐level policy negotiation
pushes the burden of communication to the sender, since the burden‐of‐computation
to the sender > > burden‐of‐verification on the receiver. In addition, the elimination of
spoofing due to this mechanism contributes to sender identification together with
the CES‐Authentication mechanisms.
● CES Authentication: CES nodes can either use the CES‐ID, which is FQDN of the
served network, or their registered RLOCs for identification purposes. By principle,
the CES node needs to authenticate the remote edge or its identity, prior to admitting
a flow from it. After spoofing has been eliminated, which is a pre‐requisite of
authentication, a centralized trusted server can verify the authenticity of the CES‐ID
or its RLOCs. In more practical cases, CES nodes can leverage the trust on X.509
certificates issued by well‐known Certificate Authority (CA) to authenticate CES‐ID
of the remote network. A remote edge can also be authenticated if its certificate is
endorsed by one of the CES‐IDs that the CES node trusts, similar to a Web‐of‐Trust
(WoT) model.
● Header Signature: the CETP signalling is generally agnostic to the underlying
technologies, that is, IPv4, IPv6, HIP, TLS/TCP and others. Some of these underlying
protocols already have some level of certificate enforcement, for example in TLS.
However, for all the other protocols, it is possible to provision the signed CETP
header within the CETP signalling such that the receiver can verify it to authenticate
CES node using the CA certificate for CES‐ID.
● Secure signalling: although the CETP signalling is agnostic to the underlying proto‑
cols, the use of protocols such as TLS/TCP, HIP, and IPSec. can contribute to the
security and reliability of the signalling channel between CES networks, due to under‑
lying technology. Similarly, the CES nodes can choose to exchange signalling over
private‐links, which could be more secure and hence preferred compared to the pub‑
lic links between networks.
● Policy‐based Communication: compared to the best‐effort principle of the Internet,
which favors the senders, the policy‐based communication in CES allows meeting the
interests of the receiver with interests of the sender, and hence filters the unwanted
traffic. In addition, it asserts the identities, authenticates the hosts, and executes host‐
level firewalling to filter the unwanted traffic.
9.3.5 Realm Gateway
The CES framework constitutes of Realm Gateway (RGW) function for incremental
adoption of the technology and inter‐operability with the legacy IP networks. RGW can
be employed as an independent standalone solution or as a part of CES. For outbound
connections, its behaviour resembles a traditional NAT that allows the hosts in its
210
the classical Internet weaknesses of address spoofing, unwanted traffic and DoS prior to
admitting a flow from the sender. CES provides the above mechanisms as policy‐
controlled features for network administrators, and gives different level of assurances
based on the configured mechanisms. We briefly describe these mechanisms that
minimize the risks to CES from Internet abuse:
● Proof‐of‐Work: is an effective method in many anti‐spamming and anti‐flooding
proposals, since it makes it difficult for the sender to flood the victim with a large
number of flows. The use of this mechanism in network‐level policy negotiation
pushes the burden of communication to the sender, since the burden‐of‐computation
to the sender > > burden‐of‐verification on the receiver. In addition, the elimination of
spoofing due to this mechanism contributes to sender identification together with
the CES‐Authentication mechanisms.
● CES Authentication: CES nodes can either use the CES‐ID, which is FQDN of the
served network, or their registered RLOCs for identification purposes. By principle,
the CES node needs to authenticate the remote edge or its identity, prior to admitting
a flow from it. After spoofing has been eliminated, which is a pre‐requisite of
authentication, a centralized trusted server can verify the authenticity of the CES‐ID
or its RLOCs. In more practical cases, CES nodes can leverage the trust on X.509
certificates issued by well‐known Certificate Authority (CA) to authenticate CES‐ID
of the remote network. A remote edge can also be authenticated if its certificate is
endorsed by one of the CES‐IDs that the CES node trusts, similar to a Web‐of‐Trust
(WoT) model.
● Header Signature: the CETP signalling is generally agnostic to the underlying
technologies, that is, IPv4, IPv6, HIP, TLS/TCP and others. Some of these underlying
protocols already have some level of certificate enforcement, for example in TLS.
However, for all the other protocols, it is possible to provision the signed CETP
header within the CETP signalling such that the receiver can verify it to authenticate
CES node using the CA certificate for CES‐ID.
● Secure signalling: although the CETP signalling is agnostic to the underlying proto‑
cols, the use of protocols such as TLS/TCP, HIP, and IPSec. can contribute to the
security and reliability of the signalling channel between CES networks, due to under‑
lying technology. Similarly, the CES nodes can choose to exchange signalling over
private‐links, which could be more secure and hence preferred compared to the pub‑
lic links between networks.
● Policy‐based Communication: compared to the best‐effort principle of the Internet,
which favors the senders, the policy‐based communication in CES allows meeting the
interests of the receiver with interests of the sender, and hence filters the unwanted
traffic. In addition, it asserts the identities, authenticates the hosts, and executes host‐
level firewalling to filter the unwanted traffic.
9.3.5 Realm Gateway
The CES framework constitutes of Realm Gateway (RGW) function for incremental
adoption of the technology and inter‐operability with the legacy IP networks. RGW can
be employed as an independent standalone solution or as a part of CES. For outbound
connections, its behaviour resembles a traditional NAT that allows the hosts in its