Subject: [Hipsec] TRANSPORT_FORMAT_LIST issues in 5201-bis and 5202-bis

From: René Hummen <[email-masked]>
Date: Wed, 26 Jun 2013 11:58:25 +0200

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/

---

From: René Hummen <[email-masked]>
Date: Wed, 26 Jun 2013 13:21:11 +0200

On 26.06.2013, at 11:58, René Hummen <[email-masked]> wrote:

[...]

> Regarding 5202-bis:

According to 5201-bis, the transport format type is defined as [1]:
"The TF type numbers correspond to the HIP parameter type numbers of the respective transform parameters."

Hence, the last sentence of my suggested text should rather read as follows:
"The transport format type for IPsec ESP is the type number of the ESP_TRANSFORM parameter, i.e., 4095."

BR
René

[1] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-11#section-5.2.11

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 26 Jun 2013 22:45:12 -0700

Rene, inline below...

> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of René Hummen
> Sent: Wednesday, June 26, 2013 2:58 AM
> To: [email-masked] WG
> Subject: [Hipsec] TRANSPORT_FORMAT_LIST issues in 5201-bis and 5202-bis
> 
> 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:
> "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.

I agree.

> 
> 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.
> 
> "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."
> 
> "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]."

I agree with all of the above suggestions.

> 
> 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?

I think it would help to at least mention here that other documents such as 5202-bis will specify what to do about any specific transport selected (and to expect to have to process this parameter in the received I2).

If there are no other comments, I will apply the above changes shortly.

> 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]:
> 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)."

I agree with this (and also with your separate post to resolve the '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?
> 

Here, I think the impact may be that it is not aligned with other negotiations in which the responder provides the list for the initiator to choose from.  By delaying it as you suggest, the initiator will be sending the list of acceptable transforms and the responder choosing.  

As is currently specified, the inclusion in R1 also adds clarity to the TRANSPORT_FORMAT_LIST in the sense that the responders clarifies to the initiator, e.g. "I accept ESP, and by ESP, I mean the suites defined in this ESP_TRANSFORM list", and the initiator can decide to proceed or not based on that information.

The downside to the current text seems to be that some bytes may be wasted in starting the transform-specific negotiations for possibly unselected transforms.  I don't know how much this would occur or be a problem in practice.  

- Tom

---

From: René Hummen <[email-masked]>
Date: Thu, 27 Jun 2013 11:19:47 +0200

> Here, I think the impact may be that it is not aligned with other negotiations in which the responder provides the list for the initiator to choose from.  By delaying it as you suggest, the initiat…

Ok, but the Initiator already proposes the DH_GROUP_LIST in HIPv2.

> As is currently specified, the inclusion in R1 also adds clarity to the TRANSPORT_FORMAT_LIST in the sense that the responders clarifies to the initiator, e.g. "I accept ESP, and by ESP, I mean the…

That's actually a good point.

> The downside to the current text seems to be that some bytes may be wasted in starting the transform-specific negotiations for possibly unselected transforms.  I don't know how much this would occu…

We could argue that resource-constrained devices will probably restrict support to a single transform for the sake of minimizing ROM overhead and that the additional parameter adds negligible overhead in unconstrained scenarios. With this line of argumentation, we can leave the negotiation in 5202-bis as it is today. Other opinions?

BR
René