IEEE C802.16m-10/0346
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Reducing OTA encryption PN (16.2.5)
Date
Submitted
2010-03-05
Source(s)
Elad Levy, Xiangying Yang, Avishay Shraga,
Chagnhong Shan
elad.levy@intel.com
Intel Corporation
Re:
IEEE 802.16-10/0011, “IEEE 802.16 Working Group Letter Ballot #31: Announcement”
Abstract
The contribution proposes a method for reducing the PN field sent OTA.
Purpose
To be discussed and adopted by TGm
Notice
Release
Patent
Policy
This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It
represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion.
It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any
IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion
to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also
acknowledges and accepts that this contribution may be made public by IEEE 802.16.
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and
<http://standards.ieee.org/guides/opman/sect6.html#6.3>.
Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and
<http://standards.ieee.org/board/pat>.
1
IEEE C802.16m-10/0346
Reducing OTA encryption PN (16.2.5)
Elad levy, Xiangying Yang, Avishay Shraga, Changhong Shan
Intel Corporation
1. Introduction
802.16m standard defines an encryption mechanism in the PDU level. As such, all encryption overhead are
added at a per PDU basis. Those overheads defined in [2] are:
-
For AES-CCM mode 7/11B composed of 3B PN+EKS field and 4/8B ICV field
-
For AES-CTR mode 3B of PN+EKS
For cell edge situations where the MS is power limited, UL allocation is expected to be small leading to small
PDU size with rather high percentage of PDU overhead consumed in each UL transmission.
The following contribution attempts to reduce the per PDU encryption overhead by sending a 1B shorter
PN+EKS field. This will be achieved by sending just the 14 LSbs of the PN field instead of sending the whole
PN field of 22bits as currently defined in [2].
The receiver will be required to track the PN value and complete the 8 MSbs upon receiving a PDU according
to the highest PN previously received. Sender is just required to drop the 8MBbs from the PDU after using the
whole 22 bits in the PDU encryption.
A sync mechanism that will carry the full PN was considered for use between the sender and the receiver, but
we feel there is no need to be concerned with loss of sync. Since an OTA PN of 14bits will allow a range of
8192 PN values and since the receiver manages a PN window of up to 1024 (i.e. PN can go back by max 1024),
only a large increase of more than 7168 can cause a loss of sync between the sender and the receiver. Assuming
the sender increments the PN by 1 for each PDU, such increase will require the receiver to miss more than 7168
PDU in a row, without acknowledging them and is not expected without a real link loss.
2. Text proposal for inclusion in the 802.16m draft
[Modify second and third paragraphs of section 16.2.4.6 as indicated]
The Advanced Generic MAC Header and extended headers shall not be encrypted. The receiver determines
whether the payload in the MAC PDU is encrypted or not from the Flow ID in the AGMH for the transport
connections. The encryption information needed to decrypt a payload at the receiving station is present at the
beginning and at the end of the connection payload except for 8 MSbs of the PN field. The PDU shall contain
only 14 LSbs of the PN while the 8 MSbs will be implicitly maintained by the sender and the receiver per SA.
For example in case of AES CCM, PN & EKS are present at the beginning of connection payload and ICV is
appended at the end of the connection payload in MAC PDU as shown in Figure 394.
If multiple connection payloads are transmitted in same burst and the connections are mapped to same SA then
multiple connection payload may be multiplexed before encryption and multiplexed payload is encrypted
together. The receiver shall perform the decryption and data authentication on the multiplexed payload, as
specified by the SA. The receiver determines whether the payloads in the MAC PDU is encrypted or not from
the Flow ID in the AGMH for the transport connections. The encryption information needed to decrypt the
2
IEEE C802.16m-10/0346
multiplexed payload at the receiving station is present at the beginning of the first connection payload and at the
end of the last connection payload except 8 MSbs of the PN. For e.g. in case of AES CCM, PN & EKS are
present at the beginning of connection payload 1 and ICV is appended at the end of the connection payload n in
MAC PDU as shown in Figure 395.
[Note to Editor: replace “22 bits” in figure 394 with “14 bits”]
[Note to Editor: replace “22 bits” in figure 395 with “14 bits”]
[Modify section 16.2.5.2.3.1.1 page 172 lines 36-43 as indicated]
PDU payload format
The MAC PDU payload shall be prepended with a 2-bit EKS and a 2214-bit PN (Packet Number). The EKS
and PN shall not be encrypted. The plaintext PDU shall be encrypted and authenticated using the active TEK,
according to the CCM specification using the full 22 bit PN value. This includes appending an integrity check
value (ICV) to the end of the payload and encrypting both the plaintext payload and the appended ICV where
the size of ICV is decided by either 4 or 8 byte during key agreement procedure in network entry.
[Modify section 16.2.5.2.3.1.1 page 172 lines 51-61 as indicated]
Packet number (PN)
The 22-bit PN associated with an SA shall be set to 1 when the SA is established and when a new TEK is
installed. After each PDU transmission, the PN shall be incremented by 1. Any pair value of {PN, TEK} shall
not be used more than once for the purposes of transmitting data. The AMS shall ensure that a new TEK is
derived in both sides before the PN on either TEK for downlink or TEK for uplink reaches maximum value
0x1FFFFF or 0x3FFFFF, respectively. If the PN on either TEK for downlink or TEK for uplink reaches
maximum value 0x1FFFFF or 0x3FFFFF, respectively, without new TEKs being installed, transport
communications on that SA shall be halted until new TEKs are installed.
[Modify section 16.2.5.2.3.1.1 and add the following after page 174 lines 51]
The receiver will manage a predication algorithm to complete the 8MSbs of the PN field not included in the
transmitted PDUs. Those 8 bits will be set to 0x00 for DL and to 0x80 for UL when the SA is established and
after each TEK refresh. Receiver operates and maintains PN_WINDOW based on 22bit PN space, constructed
from its locally managed 8bit MSb and received 14bit LSb.
[Modify section 16.2.5.2.3.1.2 as indicated]
The MAC PDU payload shall be prepended with a 2-bit EKS and a 2214-bit PN. The EKS and PN shall not be
encrypted. Construction of the counter blocks is same as counter blocks of AES-CCM.( i.e. the counter blocks
CTRj and NONCE are formatted as shown in Figure 404 and Figure 402, respectively.)
3. Reference
[1] 802.16-2009, Part 16: Air interface for broadband wireless access systems, May 2009
[2] P802.16m/D4, Draft amendment to IEEE Standard for Local and metropolitan area networks Part 16: Air
3
IEEE C802.16m-10/0346
Interface for Broadband Wireless Access Systems, February 2010
4