[Main] [News] [Introduction] [Background] [Design goals] [Architecture] [Crypto]
[Performance] [Applications] [Download] [Publications] [Contact] [Links]

Packet Level Authentication (PLA): Architecture

Elementary concept

In our previous 007-project, we came up with the general idea to port the analogy of security measures with 100 euro note to the IP-world. The idea fits to the network level where every IP packet must be verified for its authenticity.

Thus we can state the basic requirement of the solution:

Without prior communication with the sender of the packet, any node must be able to verify that the IP-packet is authentic using predefined security procedures.

This is one of the crucial requirements listed in Design goals (DG5. Contrarily to standard security protocols, such as IPsec, we have set the requirement to apply for any receiver on the path from the originator of the packet to the final destination of the packet. Thus, our solution is capable to detect false, erroneous, duplicated, and delayed IP-packets in every router, not only at the final destination. Therefore, our solution is capable of restricting various attacks, such as flooding, DDoS, and DoS, that are based on spoofing/forging IP packets and copying or manipulating legitimate IP-packets. The physical notes can be secured against duplications by making them difficult to be copied, but IP-packets can be easily duplicated. Thus, we need additional security solutions to cope with both duplicates and replayed packets.

The main operating principle of our initial solution from the 007-project is based on a "self-sufficient container of information" added into every IP-packet to contain the proof of origin of the packet [Candolin02, Kari03, Kari03a]. Based on standard IP-packet header extension techniques, used for example in Mobile IP, we add an extra header into every IP-packet [RFC3344, Johnson03].

First PLA prototype

During the year 2004, Janne Lundberg at Laboratory for Theoretical Computer Science has made the preliminary proof-of-concept implementation of PLA and we demonstrated its operation in April 2004 in Security Forum Workshop 2004, held in Espoo, Otaniemi. In this implementation, the additional header contains the following information:

  • Node level information
  • The identity of the trusted third party that has certified the node
  • The node's public key
  • The validity period
  • The certificate from the trusted third party that certifies the node
  • Packet level information
  • Timeliness of the packet
  • The sequence number of the packet
  • The originating node's signature over the packet
  • With the node level information, any node (on the path from the originator to the final destination) that trusts the listed third party can verify that the originator of the packet is still among the trusted nodes without prior communication with that node. With the packet level information, that node can then verify that the originator of the packet has really generated this packet and the packet is not altered on the path from the originator to the receiver. Also, the node can verify the timeliness of the packet. Duplication of the packet is detected by using the sequence number. Thus, corrupted, old, and duplicated packets can be discarded.

    This proof-of-concept implementation of PLA used RSA public key algorithms in signing the certificates on the node's validity and the node's signature over the packet. This meant large overhead on every packet. Therefore, the PLA project has focused on selecting more suitable digital signature algorithms. This is also important since the digital signature calculation adds significant computation requirements both on the sending and verifying nodes. Both HW and SW solutions of the digital signature algorithms are needed in order to demonstrate that our solution is scalable from small, moderate CPU devices (such as sensor and handheld devices) to high capacity core network backbone routers (having several 1GE or 10GE interfaces).

    New PLA protocol header

    The extra header used by the PLA architecture is illustrated in Figure 1. This header uses the standard IPv6 header extension technique and is thus fully transparent and interoperable with routers that do not understand the PLA protocol. This means that PLA can be used together with any other protocols, such as Mobile IP or IPsec. If the PLA header is the first header in the packet, it protects both the data and all the other headers in the packet. Since PLA uses the standard IP header technique, the maximum IP packet size (MTU) handling is done correctly.

    Figure 1: PLA header insertion to standard IP packet

    The PLA header consist of seven fields divided into two categories based on the initial idea from the 007-project:

  • Node level information
  • Auth_id:
    The identity of the trusted third party that has certified the node (i.e., the identity that has authorized the node, this can be for example a general, TTP, access-network operator, home operator)
  • Pub_key:
    The node's public key (this public key is used by the verifying node to validate the sending node's signature)
  • Val_period:
    The validity period (this field indicates when the public key is considered to be valid by the trusted third party)
  • Auth_signature:
    The certificate from the trusted third party that certifies the node (that the public key and validity period are correct)
  • Packet level information
  • Time:
    Timeliness of the packet (i.e., time when the packet was sent; it can be used to discard old packets)
  • Seq_number:
    Sequence number of the packet (this monotonically growing field can be used in discarding duplicates and replay attacks)
  • Node_signature:
    The originating node's signature over the packet (this signature field ensures that the IP packet has really generated by the sending node and it has not been altered on the path)
  • Sending and receiving PLA enforced IP packets

    When the originating node sends an IP packet, it fills the PLA header by taking the node level information (that is packet independent), incremented sequence number and current time. Finally, it calculates a signature over the entire packet and puts the result into the header. Then the IP packet is sent as any normal IP packet.

    When a node receives the first packet from the sending node, it first validates the node level information and after that the packet level information. If any of the PLA fields is invalid or incorrect, the receiving node discards the packet and optionally informs its upstream neighbor about the problem. For the subsequent packets from the same sending node, it is not needed to validate the node level information if the verifier caches the previous validation results. Then, only the packet level verification is needed. Hence, the number of digital signatures that must be validated is reduced from two signatures per packet to just one in case of several packets from the same sender.

    [TCS main] [Contact Info] [Personnel] [Research] [Publications] [Software] [Studies] [News Archive] [Links]
    Latest update: 30 April 2008.