This is the second part in the Autonomic Network series. We have introduced previously in our first part the Autonomic Network (AN), took a look about the needed configuration to run it on Cisco gear and what is the expected communication flow. In this post, we will dive deeper to have a closer look on the packets and how they are composed. Cisco’s AN protocol is a proprietary one and as far as I know, the analysis provided here for the protocol is the first of its kind.
Before I begin the analysis, I would like to thank Marc Heuse for his contributions to the protocol analysis.
The AN protocol consists mainly of 3 phases:
- Channel Discovery
- Adjacency Discovery
- Secure Channel
In the Channel Discovery (CD) phase, the registrar and the enrollee exchange messages on the layer 2 level, these messages are mainly used to discover if there are any autonomic capable device around.
The Adjacency Discovery (AD) phase runs on layer 4 and specifically UDP port 4936. It has mainly 3 parts:
- Joining request from the enrollee and the registrar’s response with either acceptance or rejection
- In case of the acceptance, we enter the Bootstrap part where the enrollee generates a 3072-bit key and request from the registrar a domain certificate.
- Finally, the speaking devices agree on the security parameters for the 3rd phase which is the secure channel.
The last phase is the Secure Channel phase, within this phase all the communication between the nodes are encrypted and authenticated. The channel can be secured using IPsec or DIKE (it is a new technology developed by Cisco and it is always the preferred mechanism for securing the channel)
As a result, one expects on capturing the traffic between the communicating parties, one will see the 3 phases; a layer 2 protocol then UDP 4936 then UDP 5000 (DIKE port). However on checking the wireshark capture, that’s what is found
All the packets are believed to be LLC (it is a layer 2 technology) and no UDP packets are shown. As a result, we decided to analyze the packets manually.
The first frame can be analyzed as the following:
Destination MAC Address
This is a 6-byte length field, the one used in the frame is a multicast MAC address registered by Cisco for the AN protocol.
Source MAC Address
This is a 6-byte length field for the source MAC address.
Frame Length
This is a 2-byte length field for the frame length in bytes without taking MAC
address fields nor the length field into consideration.
DSAP, SSAP and Control
The LLC header of 3-byte field length, its value is assigned to 0xaaaa03 as an indicator of being a SNAP frame.
OUI
This is a 3-byte field length, which acts as the Organization Unique Identifier. The value used by Cisco is 0x00000c
Protocol ID
The is a 2-byte field of the protocol ID assigned by Cisco for the AN Channel Discovery header. It has a value 0x88ef.
After that starts the CD header, according to our analysis the upcoming information can be analyzed based on the following header:
Version
This is a 4-bit field showing the version of the protocol used, for all the CD frames captured this field is always set to 1.
Reserved
This is a 4-bit field which is set to zeros.
State
This is 1-byte field that determines the state of the protocol. For the channel discovery phase it has a value of 0x01.
Factory Default
It is a 2-byte field of a fixed value of 0x00ff.
Operation Code
It is a 2-byte field for the message type. The available message types with their significance are shown in the next table
Length
It is a 2-byte field length. It corresponds to the length of the channel discovery header.
Reserved
It is a 4-byte field with a fixed value to all zeros.
TLV
Available field types are shown in the following table
With this, we finish the CD header analysis, next step is to analysis the AD header. The AD phase information can be analyzed also based on the same header.
The first packet sent by the registrar as domain announcement is shown below
The AD packets can be analyzed as the following:
Ethernet 802.3/802.2 SNAP
First 22 bytes
Customized CD header
State= 0x05 and it has an ether-type of IPv6 at the end
IPv6 header
40 bytes
UDP Header
8 bytes
From here starts the AD packet information, it can analyzed as follows:
Version
This is a 4-bit field with value 1 for the old images (before 2016) and 2 for the newer ones.
Reserved
This is a 4-bit field of all zeros.
State
This is 1-byte field that determines protocol state; available states are shown in following figure
Factory Default
It is a 2-byte field of a fixed value of 0x00ff.
Operation Code
It is a 2-byte field for the message type. Available operation codes and their significance are shown below
Length
It is a 2-byte field length. It corresponds to the length of the adjacency discovery header.
Reserved
It is a 4-byte field with a fixed value of all zeros.
TLV
Available field types with respect to the operation codes are shown below
The Secure Channel phase is based on open standards protocol and their packets are clearly explained in their respective RFCs.
With this we reach the end of the post, stay tuned for the 3rd part where we use the protocol analysis to find vulnerabilities within the AN.
Cheers,
Omar
====================Update==========================
It is such a pleasure to announce that WireEdit 1.10.118 is the first application to support editing and the analyzing of the Cisco Autonomic Network protocol based on this article.
===================================================
May I have pcap(s) with this traffic? I can build an analyzer for the protocol. Having logs make it easier to start.
Is it possible to get the pcap logs you’ve used, or some subset of them?
Hi Michael,
thanks for taking interest in my work, I will send you one of the pcap(s). It contains all the packets mentioned in this article.