Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis

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

> -----Original Message-----
> From: Petri Jokela [mailto:[e-mail]]
> Sent: Thursday, June 13, 2013 11:58 PM
> To: Henderson, Thomas R; HIP
> Cc: [e-mail]; [e-mail] Melen
> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis
> 
> 
> On 11.3.2013, at 23.57, Henderson, Thomas R wrote:
> 
> > This is a WGLC review of RFC5202-bis.
> >
> > This draft seems to be close to being ready.  There are two areas
> (more detail below) that IMO could be clarified or else left out of
> scope:
> >
> > 1) handling of simultaneous IPsec and HIP ESP
> 
> 
> Hi,
> 
> I somehow missed this point when I was fixing the document. I'm not
> sure what we should do with this, any comments or suggestions?

I posted the comment, which said:

"Section 3.4, third paragraph.  I don't know the basis for the assertion that HIP SA processing takes place always before the IPsec processing.  Isn't this implementation dependent?  What HIP processing is being referred to here, pseudo-header manipulation, or more?  Can we delete this paragraph, or otherwise clarify? "


> Currently the document says:
> 
> 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 ensure that
>    the SPI values used for HIP SAs are not used for IPsec or other SAs,
>    and vice versa.
> 
>    In the sending host, the HIP SA processing takes place always before
>    the IPsec processing.  Vice versa, at the receiving host, the IPsec
>    processing is done first for incoming packets and the decrypted
>    packet is further given to the HIP processing.
> 
>    Incoming packets using an 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 as specified in [I-D.ietf-hip-rfc5201-bis].
> 
> 


I propose to delete the paragraph starting with "In the sending host,..." if there are no other comments.  I don't understand the use case that is suggested by this paragraph.

- Tom