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

[Mark Townsley <[e-mail]>]

It sounds like this addresses the concern in terms of "truth in 
advertising" here, and I am very glad to see this as it is certainly 
important. I wonder if the IPsec community will have architectural 
issues with SPIs being attached to specific processing above the IP 
stack (depending, I suppose, on where you consider HIP, IP, and IPsec in 
relation to one another). I remember somewhat similar cases in the past 
causing serious heartburn within the IPsec community.

cc'ing Sam and Russ for their opinion.

- Mark

Petri Jokela wrote:
> Mark Townsley wrote:
>>
>> The Security Area has asked for the following:
>>
>> An explicit section describing why the semantics of HIP ESP differ 
>> from IPsec ESP,and explaining how a node can run both IPsec and HIP.  
>> If a node cannot run HIP and IPsec at the same time in all 
>> configurations of HIP, you are likely to see significant pushback.
>>
>> Such a section sounds reasonable. Also, is the latter true or false?
>>
>> Thanks,
>>
>> - Mark
>
> Hi,
>
> we discussed with Jan about this and he wrote a proposal for a new 
> subsection describing what has to be considered when HIP is used 
> together with other keying protocols. This limits implementation 
> possibilities, but I hope it
> is not too restrictive to be written on the specification.
>
> BR, Petri
>
>
> 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).
>
> 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.
> 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.
>
> /petri
>

_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec