CNS - 15 - DIAMETER

From the point view of the single user, connecting to a RADIUS network consists in the transmission of 2 UDP packets.

So why is this a problem in terms of scalability?

Well, consider a NAS unit which has 48 ports, and assume that communication arrive and last for an average of \(20\) minutes. This means that every \(25\) seconds there is a new request for entering the RADIUS network. Now suppose you have \(10.000\) of such NASes. Then you have \(400\) access-requests/second. Then you'd have \(3.2\) mbps server load if request average \(1KB\). This is actually not that much, but some software implementation might not be able to survive a load of \(10\) mbps.

Observation: If you have a phenomenon that creates dependency, you have load peaks in which lots of requests are sent.

IETF Stands for Internet Engineering Task Force, which is the institution that defines the standards the technologies used in the Internet.

Throughout the years they have moved to improve the RADIUS protocol in various directions:

• DIAMETER: On the one hand they created a new protocol called DIAMETER, which features a really rich and expressive language.

• RADext: Since most people will not change protocol, another approach was to extend the RADIUS protocol.

• RADIUS/Diameter compatibility: At the end of the day they decided to keep them both. Sometimes duplicating the work is the best strategy, since it lets you bet on a new solution while keeping the old one supported.

Observation 1: The PPoE/PPoA protocol was meant to last for a short-while in order to move to full Ethernet connectivity. After \(20\) years it is still being used.

The DIAMETER protocol can thought of as a sort of "object-oriented protocol". It can be be visualized as follows

DIAMETER is not an AAA protocol, but is a general application level messaging protocol. It can be broken down in three components:

• AAA transport profile: This tells you how to implement the support at the transport layer for a general messaging protocol.

• DIAMETER Base Protocol (RFC 3588): which specifies all the primitives to support signaling exchange and messaging exchange, irrespective of what is the specific application.

• DIAMETER applications: For every different usage that you can do of the messaging protocol a particular protocol is defined. The particular app used to authenticate user is the Diameter NAS app (RFC 4005).

Consider a NAS which wants to talk to a AAA server. To do this a reliable communication channel has to be set-up. You can approach this in two ways:

• The stupid way: you set up a TCP connection for ever new call. This is not efficient at all, since for every connection you have to complete the handshake with \(3\) packets.

• The not so stupid way: you set up an initial TCP connection to the server, which you then use multiple times for the various authentication requests. Even this way is not efficient however, because if the AAA is a multi-threaded application, if one flow of packets is stuck, all the others are stuck too, because TCP enforces a strict order in the delivery of the packets.

Suppose you want to have a reliable connection which is used to send different streams, each of which can be made of multiple packets. In this case you'd want a protocol which guarantees that all the packets in a given stream are read in the correct order, but that packets beloging to different streams are not ordered at all. This cannot be done in TCP. Indeed, the fact that when embedding multiple streams in a single TCP connection the blocking of one packet in a stream leads to the blocking of all the other packets in the other streams, is called head of the line blocking (HOL), and is one of the first major problem of TCP. In general HOL is one of the worst thing that happens in complex systems, and it happens a lot in traffic.

Another problem of TCP is that if you change the IP source you need to create a new TCP connection, meaning that you can't change connection fast to a backup link if the current link fails. This is called multi-homing, and it consists in using multiple IPs that can be used in case one of the connction failed.

Observation: A new protocol called MPTCP (Multi-Path TCP) which solves this particular problem. MPTCP is more recent than STCP.

Why if the SCTP is a better protocol than TCP, then it is not used as much? This question can be answered by explaining what is the internet ossification.

The original idea of the internet, the End to End Principle, was to put all the "intelligence" on the edge of the network, while having the center just to do routing and small work. At the start this worked, but then, as time went on, lots of so-called "middle boxes" were started to be built such as NATs, Firewalls, Media Converts, TCP accelerators, and so on.

At some point there were so many of these middle boxes in the center of the Internet that if you tried to use a new protocol like SCTP, these boxes simply blocked your packet. The vendors said: we will support SCTP when we know it is used by many people. Yet, many people will not use it because it is not supported by vendors. Thus we have a chicken/egg problem. It is a fact that from \(2000\) to \(2015\) internet development was blocked for this reason. This was called the internet ossification.

Now the situation is different because we have softwared defined networking, which allows vendor to deploy instantly software updates to these devices.

Observation: The softwarization of the network is the best aspect of 5G.

Three types of agents operations:

• No intermediate agent

  

• Relay agent

  

• Proxy agent: as relay but modifies the message (e2e message auth is broken).

• Redirect agent: The idea is to have a redirect agent which provides routing decision on incoming requests. This agent does not actually route request, but rather returns redirects. This is useful when diameter routing decisions are centralized, for exmaple in a consortium (e.g. eudoram).