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

["Henderson, Thomas R" <[e-mail]>]

Rene, inline below...

> 
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of René Hummen
> Sent: Wednesday, June 26, 2013 2:58 AM
> To: [e-mail] 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:
> ----------------------------
> 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.

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

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.

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

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