1 IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec Title: Fragmentation and Security Protection Date Submitted: March 8, 2011 Present at IEEE March meeting Authors: Lily Chen and David Cypher (NIST) Abstract: This document proposes two options to resolve comment #191 in letter ballot 5a to incorporate data expansion due to security protections to fragmentation xx-00-sec

xx-00-sec2 IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) 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 The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/board/pat/faq.pdf

What are the issues? In D02, no changes on the fragmentation are included. However The security protections will bring about data expansion. Fragmentation needs to consider the data expansion. Otherwise the message length may exceed the MTU after applying security protections. Currently, the inner header has identical data fields as the security header, except the security related bits (P bit and S bit). The inner header is protected with the selected ciphersuite, which may not be needed, since the plaintext header must be sent.

Data Expansion due to Applying Security Protections Ciphersuite CodeEncryptionIntegrity protectionExpansion AES-CBCHMAC-SHA (IV)+96(MIC)+127 (Padding)* = 351 bits NullHMAC-SHA (MIC) bits NullCMAC-AES96 (MIC) bits AES_CCM80 (SN) + 96 (MIC) = 176 bits * Here it is assumed that cipher stealing is not used. The ciphertext needs to carry the padding bits. If originally an aFragmentationThreshold is set (by link layer or by default), then when security protections are applied, then in order to make sure that the security protected message does not exceed MTU, the aFragmentationThreshold will be reduced to aFragmentationThreshold -d. Based on the supported ciphersuites, the maximum expansion is 352 bits (or 44 octets). We select d = 44 octets

Which options do we have? 1.Integrate fragmentation with security protections; 2.Add a security protection triggered fragmentation on the top of the old fragmentation.

Option 1: Integrated solution Fragment with a new aFragmentationThreshold, which considers data expansion d. Apply protection on the fragmented message; Include the fragmentation information in the MIH security header; No inner header is needed. The fragmentation and security protections are applied in one pass.

Option 1: Illustration Assume aFragmentationThreshold = 5 units and data expansion d = 2 units. Security header has 1 unit. Assume that the data to be protected are A, B, C, and D each of which represent 1 unit. ABC D SS 2 units security data HsHs 1 unit Security header.Data to be protected ABSSHsHs CDSSHsHs M =1, FN = 1M =0, FN = 2 Security protection and fragmentation

Option 2: Security triggered Obtain a (maybe fragmented) message with a header which includes the fragmentation information. If after applying security protection, the length exceeds aFragmentationThreshold, then fragment before applying protections. The new fragmentation information is carried in the MIH security header. At the receiver end, reassembly is done base on the security header before passing to the original reassembly function. The inner header is still needed for the original reassembly function to use.

Option 2: Illustration Assume aFragmentationThreshold = 5 units and data expansion d = 2 units. Original MIH Header and MIH security header both has 1 unit. Assume that the data to be protected are A, B, C, and D each of which represent 1 unit. SSHsHs BCSS HsHs M =1, FN = 1 M =1, FN = 2 A DHOHO HsHs SS M =0, FN = 3 ABCD SS 2 units security data HsHs 1 unit MIH Security header. Data to be protected HOHO 1 unit Original MIH header. HOHO M = 0, FN = 1 ABCD Fragmentation without considering security Fragmentation when applying security protection

Discussion Option 1 is the optimized solution. It will conduct fragmentation and security protection in one pass. It only needs to carry one header (security header). The impact to the current document is to change subclause to include security data expansion. That is, to change aFragmentationThreshold to consider d = 44 octets brought about by security protections. Option 2 requires two fragmentation functions. It can leave the original fragmentation unchanged. However, if the original fragmentation is not implemented yet, then this reason cannot be counted. The impact to the current document is to include a new subclause in Clause 9 for security triggered fragmentation and reassembly.

Proposal Adopt option 1. Add a modification to subclause