RE: [Hipsec] draft-ietf-hip-esp-03

I have a few comments on this proposed text.

> 3.4 IPsec and HIP ESP implementation considerations
> 
> When HIP is run on a node where a standards compliant IPsec is used,
> some issues have to be considered.
> 
> The HIP implementation must be able to co-exist with other 
> IPsec keying
> protocols. When the HIP implementation selects the SPI value, it may
> lead to a collision if not implemented properly. To avoid the
> possibility for a collision, the HIP implementation MUST request SPI
> values from the IPsec (e.g. using PFKey interface).

I would prefer to say "MUST ensure that the SPI values used for HIP SAs
are not used for IPsec or other SAs, and vice versa."  -- less
implementation dependent description. 

> 
> For outbound traffic the HIP has to make a strict binding between the
> application socket, Security Policy (SP), and Security 
> Association (SA)
> used by HIP. Data originating from a socket that should be 
> processed as
> described in this document should have a SP that is bound to 
> the socket.

I think that the issue of binding a HIP SA to a socket is a separate
implementation/architectural issue that also exists in the realm of
IPsec (the channel binding discussion in BTNS WG).  The above text
conflicts with section 9 of the BEET draft (and also our experience)
that says that you can reuse an existing IPsec implementation (without
socket bindings) to implement HIP.

I think that it suffices to say that for outbound traffic, the SPD or
(coordinated) SPDs if there are two (one for HIP, one for IPsec) must
ensure that packets intended for HIP processing are given a HIP-enabled
SA and that packets intended for IPsec processing are given an
IPsec-enabled SA.

> The SP then MUST be bound to the matching SA and non-HIP packets will
> not be processed by this SA. Data originating from a socket 
> that is not
> using HIP, MUST NOT have checksum recalculated as described in Section
> 3.2 paragraph 2 and data MUST NOT be passed to the SP or SA created by
> the HIP.
> 
> Incoming data packets using a SA that is not negotiated by 
> HIP, MUST NOT
> be processed as described in Section 3.2 paragraph 2. The SPI will
> identify the correct SA for packet decryption and MUST be used to
> identify that the packet has an upper-layer checksum that is 
> calculated
> in HIP way. The socket that uses HIP SHOULD NOT be able to receive any
> data that has not come through the SA that was created by HIP.
> 

I don't think the last sentence adds anything.

Regards,
Tom

_______________________________________________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec