www.Lucq.org

The Alcatel DANA protocol

Introduction

As outlined on theLinDANA page, the Alcatel DANA protocol (which is sometimes also referred to as “Alcatel RAS”, or simply “DANA” protocol) was used by my ADSL provider to the authentication and connection management (since then the telco has replaced this protocol with the more widely used PPP-over-ethernet (PPPoE) protocol). This page contains some more information about the (proprietary) Alcatel protocol; a lot of this information was initially reverse-engineered by Ivo Clarysse, and can still be found at http://www.soti.org/~soggie/linux/dana-adsl/. I am not going to go into a lot of detail here, I'm merely going to discuss a few highlights. If you want to know more (although I wouldn't know why ;-) ), your best bet is probably to find one of the open-source clients and have a look at the source code.

Overview

The DANA protocol was used in the Belgacom Turboline context (my ADSL provider) to accompliush the following four goals:

1. Select a service domain and authenticate the user for this domain
2. Obtain an IP address in this service domain
3. During the connection, perform keep-alive checking
4. Allow more or less graceful disconnection

Your selected “service domain” would normally be your ISP. A selection had to be made since several ISP's provided a connection using ADSL. This service domain was identified using some mnemonic name, typical for the ISP (e.g. “SKYNET” and “EASYNET”, to name two). A typical protocol handshake mirrors the sequence of these four goals.

Handshake details

Packet format

A DANA packet has the following format:

• A small header common to all packets. This header contains the version of the DANA protocol, the type of the DANA packet, a packet sequence counter, and a session ID.
• Some data fields, specific to this type of DANA packet.
• Zero or more packet “attributes”, as appropriate for this DANA packet.

These so-called “attributes” (my terminology) also begin with a small header structure. Here the header consists of an attribute type field, followed by the total size (in bytes) of this attribute. Following this header, there come zero or more data bytes, as determined by the size field, and as appropriate for the attribute type.

The packet format outlined above appears to mimic the format used in the RADIUS protocol (RFC 2138, “Remote Authentication Dial In User Service (RADIUS)”, for those who care). This is not really a big surprise, as your typical ISP will use a RADIUS server for user authentication, and the Alcatel Broadband Access Servers specify RADIUS interoperability as one of their features.

Authentication

The AddCall packet mentioned in section two contains three important attributes:

1. The service domain name. This is a plaint-text mnemonic, identifying your ISP (e.g. “SKYNET”).
2. The login name. Again, a plain-text field, containing the login name provided by the ISP.
3. Lastly, the password for the given login name. Again, in plain text. Although the DANA protocol provides for CHAP-MD5 authentication (in other words, using an encrypted value instead of the PAP method outlined here which uses a plain-text password), I have never seen this in actual use.

Together, these three attributes select a service domain and contain the authentication information for this domain.

Final note

Due to the halting of the LinDANA program development, this protocol description will remain unfinished. If you really want to know more, I suggest looking at the source of one of the open-source client programs (for instance, the LinDANA program).