[e2e] Introduction to ATP

[Jason Gao]

Here ATP stands for Asymmetric Transport Protocol (somewhat for historical
reason), not Appletalk Transaction Protocol.

Welcome to http://atp.ebloggy.com/ to add comment.

Known problems:
Lack of references section;
Lack of elliptic curve parameter definition;
and much more:)

Briefly:

ATP aims to provide mobility and multi-home support in transport layer. But
why not patching TCP, extending SCTP, or exploiting HIP? The answer is that
when taking account of syndicate effect, it is more efficient to use ATP.

Patching TCP software to support mobility and multi-home is not difficult.
But widely deploying the new TCP implementation may be an enduring work.

SCTP supports multi-home, and it is quite easy to extend it to support
mobility. But as SCTP is already quite heavy weighted, and its congestion
control mechanism arguably suffers same trouble as TCP, it is difficulty to
persuade mass users to accept SCTP.

HIP decouples identity and locator role of IP address by adding a new layer.
It is quite exquisite. But unfortunately to add a new layer is to add a new,
non-trivial trouble of reliability.

The name of Asymmetric Transport Protocol is somewhat historical. ATP takes
advantages of asymmetric cryptography (and asymmetry of communication). It
is designed to be an alternate of transport layer protocols, alongside of
TCP and UDP [RFC768].

ATP aims to
²	Decouple locator and identity role of network layer address by keep
it from taking part in transport layer identity and/or address.
²	Support mobility
²	Support multi-home
²	Facilitate high performance parallel communication
²	Facilitate high efficiency transactional communication
²	Provide transport encryption service
²	Provide some QoS service
²	Keep simple

ATP supports mobility and multi-home by decoupling locator and identity role
of network layer address with connection key.

There are three connection modes in ATP: fast-mode, normal mode and
encrypted transport mode. In the host environment, each ATP connection is
uniquely associated with a 64-bit connection key.

In the context of each normal mode ATP connection, there is a shared secret.
The shared secret is established in Elliptic Curve Diffie-Hellman [ECC] key
agreement process when the connection is set up. ATP endpoint seals every
ATP packet with Integrity/Identity Check Code (ICC). In normal mode ICC is
calculated by applying HMAC-SHA1 [RFC2104] [RFC3174] on the ATP packet
header with the shared secret as the key. As far as only the connected peers
know both the connection key and the shared secret, integrity of the ATP
packet header and identity of the ATP packet source are secured by ICC.

In fast mode, ATP endpoints do not establish a shared secret, and agree on
the connection key only. The 64-bit connection key solely acts the identity
check role. ICC is a CCITT-CRC-16 code [CRC] that weakly protects packet
integrity.

In encrypted transport mode ATP endpoints use AES-IV-SHA1-80 algorithm to
protect privacy of the payload, integrity of the full packet, and identity
of the packet source. AES-IV-SHA1-80 algorithm is integration of AES
[FIPS-197] and SHA1-80 [RFC3174]. AES encryption key is installed by the
upper layer application (ULA), or derived from the shared secret on request
of ULA; 64-bit initial vector is the low-order 64-bit part of the result of
applying SHA1-80 on the ATP packet header. High-order 16 bits are exploited
for preliminary integrity check. Encrypted transport mode is not only a
feature of mobility and multi-home but a simple and useful feature of
security as well.

Mobility support is further reinforced by the feature of re-locating via
courier.

ATP supports high performance, high efficiency parallel and/or transactional
communication with connection clone and auto-reconnect features.

ATP also features First-In-First-Deplete traffic class, in addition to
traditional best-effort traffic class.

ATP DOES NOT provide reliable multicast support, nor does it do full-fledged
congestion control. However, ATP does have cooperative congestion control
feature.

We assume that
²	Mobility context is L4-comfortable. That is, frequency of IP address
change is limited so that the IP addresses of two endpoints remain stable as
long as they are negotiating a connection.
²	Ownership of upper layer application over connection key is secure.
²	Upper Layer Application is willing and able to defense against
man-in-the-middle attack.
²	Acceptable information asymmetry. One participant in communication,
the responder, is willing to and able to make the other participant, the
initiator, know the rendezvous key, but not necessarily vice versa.