Hi, I just noticed an issue in 5201-bis and 5202-bis related to the integration of the new TRANSPORT_FORMAT_LIST parameter. More precisely, the specification in both documents is still incomplete.
Regarding 5201-bis: ---------------------------- Section 6.7 [1] says: "6. The responder expresses its supported HIP transport formats in the TRANSPORT_FORMAT_LIST as described in Section 5.2.10. The Responder MUST at least provide one payload transport format type." First, this text should refer to Section 5.2.11 as Section 5.2.10 defines the HIT_SUITE_LIST parameter, whereas Section 5.2.11 specifies the TRANSPORT_FORMAT_LIST parameter. Second, the text above implies that the TRANSPORT_FORMAT_LIST parameter is mandatory in HIPv2 (which makes a lot of sense). However, it is currently not mentioned in sections 5.3.2 [2] and 5.3.3 [3]. Here, the parameter must be added to the packet overview as a mandatory parameter. Furthermore, I suggest to add the following text to Section 5.3.2: "The TRANSPORT_FORMAT_LIST parameter is an ordered list of the Responder's preferred and supported transport format types. The list allows the Initiator and the Responder to agree on a common type for payload protection." ... and to Section 5.3.3: "The TRANSPORT_FORMAT_LIST contains the single transport format type selected by the Initiator. The chosen type MUST correspond to one of the types offered by the Responder in the R1. Currently, the only transport format defined is IPsec ESP [I-D.ietf-hip-rfc5202-bis]." Note that the parameter is already discussed in the packet processing instructions in the subsections of Section 6.6 [4, 5]. Do we also need to define instructions in Section 6.9 [6] in order to tell implementors what to do when receiving the TRANSPORT_FORMAT_LIST parameter in an I2 message or do we leave that to documents such as 5202-bis? Regarding 5202-bis: ---------------------------- There is currently no reference to the TRANSPORT_FORMAT_LIST parameter in this document. Here, we need to specify the transform format type for IPsec ESP. I suggest to add the following new section to the document [7]: "4.1.1 IPsec ESP Transport Format Type The HIP handshake signals the TRANSPORT_FORMAT_LIST parameter in the R1 and I2 messages. This parameter contains a list of the supported HIP transport formats of the sending host in the order of preference. The transport format type for IPsec ESP is X (TBD)." Furthermore, I suggest to move the ESP_TRANSFORM negotiation to the I2 and R2 in order to complete the transport format type negotiation before starting the ESP transform negotiation. As I see it, this should not negatively impact ESP SA setup as the KEYMAT index in the ESP_INFO parameter is independent from the chosen ESP Suite ID. Or did I make a mistake here? BR René [1] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-11#section-6.7 [2] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-11#section-5.3.2 [3] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-11#section-5.3.3 [4] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-11#section-6.7 [5] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-11#section-6.8 [6] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-11#section-6.9 [7] http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-02#section-4.1 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21429 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
