Ieee p802. 21m Media Independent Services Framework Project
Figure 27—MIS protocol general frame format
Download 3.39 Mb.
|
- Navigate this page:
- Figure 28—MIS protocol header format
- Field name Size (bits) Description
- Table 23—Description of MIS protocol header fields (continued)
- 8 . 4 . 1a Pro t ec t e d MIS pro t oc ol f r am e f ormat
- Figu r e 2 8 a—Pr o t e ct ed MIS fr am e f ormat 8 . 4 . 1
- Figur e 2 8b—MIS S PD U du r i ng TL S han d sh a k e
- Figure 28c—MISS PDU in Exist e nce of MIS SA by TLS
- Figu r e 28 d —MIS PD U P r ot e c t e d b y an EAP- g en e
- Fig u r e 2 8 e— MIS PD U upo n Tr an s por t A d dre ss C h
- Figure 29—Fragmented MIS protocol frame format
- Figu r e 2 9 a—Pr o t e ct ed fr a gme n te d MIS pro t oc ol
- Message parameter TLV encoding
- Figure 30—Message parameter TLV encoding
Figure 27—MIS protocol general frame format The MIS protocol header (see Figure 28) carries the essential information that is present in every frame and is used for parsing and analyzing the MIS protocol frame.
Figure 28—MIS protocol header format Table 23 shows the description of the header fields. Table 23—Description of MIS protocol header fields
Table 23—Description of MIS protocol header fields (continued)
8.4.1a Protected MIS protocol frame format In an MIS header the following two bits are used to indicate that an MIS PDU is protected and/or is used to carry a proactive authentication message. a) P bit — Setting P bit to one indicates that the message carries a proactive authentication message. b) S bit — Setting S bit to one indicates that an MIS security association exists and the service specific TLVs are protected. A protected MIS PDU is an MIS PDU that has an MIS header with S bit set to one indicating that the MIS service specific TLVs in this PDU are protected. Each security association is defined for a pair of MISF identifiers and is identified by a security association identifier (SAID). Therefore, for a protected MIS PDU, when a security association identifier is defined, the Source and Destination MISF identifier TLVs may not be present. In this case, an MIS header is followed by an SAID TLV, which is followed by a security TLV. Figure 28a shows a protected MIS protocol frame, where the source and destination MISF TLVs are optional.
Figure 28a—Protected MIS frame format 8.4.1a.1 MIS PDU protected by (D)TLS MIS message can be protected using TLS [RFC5246] or DTLS [RFC4347]. The transport protocol for (D)TLS is the MIS protocol. When the MIS protocol transport is reliable, TLS is used. Otherwise, DTLS is used. The transport protocol entities to be associated with a TLS session are MISF peers and are identified by MISF identifiers. The TLS handshake takes place over the MIS protocol and as a result, an MIS SA that contains TLS master key and its child keys, TLS random values and the TLS cipher suite negotiated in the TLS handshake is established between the peers. The detailed description about the protocol interface of using (D)TLS is provided in 9.1.1. The structure of an MISS PDU during a TLS handshake is shown in Figure 28b.
Figure 28b—MISS PDU during TLS handshake Once a (D)TLS handshake is completed, an MIS SA is established, which is determined by the ciphersuite negotiated in the (D)TLS handshake. The structure of protected MIS PDU, when an MIS SA exists, is shown in Figure 28c, where the unprotected MIS service specific TLVs are carried and protected as (D)TLS application data. An MIS header has the S bit set to one. The TLS session ID assigned through TLS hand- shake is contained in the SAID TLV. The TLS protection can be integrity protected, encrypted, or both. If it is integrity protected, then a message integrity code (MIC) is also included in the security TLV. In this stan- dard, the message integrity code is the same as the message authentication code, for which the acronym MAC is already used for media access control. MIS Service Specific TLVs
MIS header SAID TLV Security TLV (TLS record type = application data) Figure 28c—MISS PDU in Existence of MIS SA by TLS The MIS message protection procedure is specified in 9.3. 8.4.1a.2 MIS PDU protected through EAP-generated MIS SA An MIS security association (SA) may be established through an MIS service access authentication. An MIS SA is established for a pair of MISFs. It includes a ciphersuite used for the protection. A security association identifier is assigned by the PoS as a result of successful EAP execution and communicated to the MN via a MIS_Auth request message with a Status indicating Success. Figure 28d shows a protected MIS PDU. The protection procedure is specified in 9.3.1. MIS Service
MIS header SAID TLV
Security TLV Figure 28d—MIS PDU Protected by an EAP-generated MIS SA 8.4.1a.3 Protected MIS PDU upon transport address change If the transport address of an MISF peer changes over the lifetime of a TLS session or the lifetime of an SA, the mapping between the sender's transport address and the MISF identifier shall be updated only if the MISF identifier is the same as that is currently bound to the security association identifier, and an MIS reg- istration request or response message may be contained in the Security TLV. The structure of a protected MIS PDU upon transport address change is shown in Figure 28e.
Figure 28e—MIS PDU upon Transport Address Change Fragmentation and reassembly General The MIS fragmentation mechanism is defined using 'M' (More Fragment) and 'FN' (Fragment Number) fields of the MIS protocol header. An MIS message is fragmented only when MIS message is sent natively over an L2 medium such as Ethernet. The message is fragmented when the message size exceeds aFragmentationThreshold. The size of each of the fragments is the same except the last one, which may be smaller. The maximum fragment size is defined as the maximum value of aFragmentationThreshold, which shall be equal to the Maximum Transmission Unit (MTU) of the link layer that is on the path between two MISF nodes, minus securityOverhead octets, which is the maximum expansion for each protected MIS PDU. When there is no MIS SA, securityOverhead is set to zero. The calculation of securityOverhead when there is an MIS SA is given in Annex K. When the MTU of the link layer between two MISF nodes is known, the maximum fragment size is set to the MTU (in octets) minus securityOverhead octets. The method of determining such an MTU is outside the scope of this standard. When the MTU of the link layer between two MISF nodes is unknown, the maximum fragment size is set to the minimum MTU of 1500 octets minus securityOverhead octets. When MIS message is sent using an L3 or higher layer transport, L3 takes care of any fragmentation issue, and the MIS protocol does not handle fragmentation in such cases. Figure 29 shows the components of the fragmented MIS protocol frame. The MIS protocol payload carries a Source MISF Identifier TLV and a Destination MISF Identifier TLV followed by a fragment payload. Based on the fragment size, the fragment payload may not be aligned on a TLV boundary, i.e., TLVs other than the source MISF identifier and destination MISF identifier TLVs may not be complete within the fragment payload. The fragment size may be smaller than the maximum fragment size and shall be larger than the value that can generate more than 128 fragments. 
Figure 29—Fragmented MIS protocol frame format When an MIS PDU is protected, the protection is applied to the fragment payload as shown in Figure 29a. Fragment payload Protection ((D)TLS or EAP-generated SA) MIS header SAID TLV Security TLV (Protected fragment payload) Figure 29a—Protected fragmented MIS protocol frame format Fragmentation When an MIS message is fragmented, the fragmentation is performed within 'Transmit()' procedure in the MIS transaction protocol state machines. The MIS protocol header, the source MISF identifier TLV and destination MISF identifier TLV of the original message are copied to each fragment. When an MIS SA exists, the S bit in the header is set to one and an SAID TLV is included in each fragment. In this case, the source MISF identifier TLV and destination MISF identifier TLV of the original message are optional. However the 'variable payload length', 'more fragment', and 'fragment number' fields are updated accordingly for each fragment. Variable payload length of each fragment indicates the number of octets in the MIS protocol payload of that fragment. 'More fragment' and 'fragment number' fields of each fragment are set according to the description in Table 23. When data are to be transmitted, the number of octets in the fragment shall be determined by the fragment size and the number of octets in the multi-fragment message that have yet to be assigned to a fragment at the instant the fragment is constructed for the first time. Once a fragment is transmitted for the first time, its frame body content and length shall be fixed until it is successfully delivered to the destination MISF. No retransmission by the MIS protocol (defined in 8.2) is performed for any single fragment of a multi- fragment message. Reassembly The destination MISF reassembles the received fragments into an original message. Reassembly is performed outside the MIS transaction state machines. 'MsgIn' and 'MsgInAvail' variables are set only after successful reassembly. An MISF shall be capable of receiving fragments of arbitrary length. The following fields are used for reassembling fragments: S bit
MIS message ID Transaction ID Source MISF identifier TLV Destination MISF identifier TLV SAID TLV (when Source and Destination MISF identifiers are not present) More fragment Fragment number When any fragment of a multi-fragment message has arrived first, the destination MISF starts a timer referred to as ReassemblyTimer. If this ReassemblyTimer expires before all fragments have been received, the destination MISF discards those fragments that it has received. A duplicate fragment is discarded. When S bit is set to one, the fragment is protected. The protected fragment is verified for its integrity at the receiving end. If encryption is applied, it is decrypted to obtain the plaintext fragment. The security association identifier maps the fragment to a pair of source and destination MISF identifiers that are required for reassembly. The reassembly is performed after all the fragments are verified and decrypted. An example of an original MIS message and fragmented MIS messages is shown in Annex K. Message parameter TLV encoding The following general TLV encoding (shown in Figure 30) shall be used for all parameters in an MIS protocol message. 
Figure 30—Message parameter TLV encoding Specifically, the Type field is one octet13, and the Length shall be encoded with the rules described in 6.5.6.2. Moreover, TLV Type values shall be unique within the MIS protocol. The TLV encoding starts at 1 and any subsequent values are assigned in ascending order (see Annex L, Table L.2). The TLV encoding of the vendor specific TLV (type = 100) is shown in Figure 31. 
Download 3.39 Mb. Share with your friends:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||