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

From: Mark Townsley <[email-masked]>
Date: Tue, 22 Aug 2006 10:16:54 +0200

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

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 23 Aug 2006 23:35:55 -0700

OK, I'll bite... 

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]] 
> Sent: Tuesday, August 22, 2006 1:17 AM
> To: [email-masked]; [email-masked]
> Subject: [Hipsec] draft-ietf-hip-esp-03
> 
> 

- How the semantics of HIP ESP differ from those of IPsec ESP:
See Section 5 of:
http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-06.txt

- Why the semantics of HIP ESP differ from those of IPsec ESP:
See Section 3 of:
http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-06.txt

- Can a node run both IPsec and HIP at the same time?
If one defines IPsec as including the proposed BEET mode, then the
answer is "yes," HIP can run with a proposed extension of IPsec ESP;
moreover, the only mode of HIP presently defined is one that *requires*
such ESP.  

If one defines IPsec as all modes of RFCs 430*, then strictly speaking,
I think the answer is "no," for the following reasons (there may be
more):
i) existing transport mode has issues due to the use of IP addresses and
not HITs in the upper-layer checksum
ii) tunnel mode may have issues in supporting BITW implementations?
That is, I understand from recent shim6 discussions that one cannot just
implement IPsec native in the stack; one must also be able to implement
the same SAD/SPD in BITW gateways.  Since HITs are not routable (unlike
shim6 ULIDs), it would seem to me to be difficult to do so in practice.
(By the way, no one has formally proposed using HIP with existing tunnel
mode, other than in some WG discussions I've participated in).

Tom

---

From: Jan Mikael Melen <[email-masked]>
Date: Thu, 24 Aug 2006 11:03:23 +0300

Hi Tom, Mark, and others

> not HITs in the upper-layer checksum

The upper-layer checksum is indeed calculated with HITs, but I don't see what 
is the problem with the checksum. 

On inbound packet:
The implementation has to keep track of the SPIs used for HIP connections and 
apply the upper-layer checksum verification method using HITs proposed in:
http://www.ietf.org/internet-drafts/draft-ietf-hip-esp-03.txt section 3.2 
paragraph 2.

On outbound packet:
A strict binding between the socket, SP and SA is needed so that the packet 
which checksum was calculated using HITs will end up to the SA created by 
HIP.

If then IKE or any other keying protocol creates a SA in the host with same 
end points the upper-layer checksum verification is then done using IP 
addresses. The SPI value will be anyway different in different SAs.

> mode, other than in some WG discussions I've participated in).

Tunnel mode should work fine with HIP as long as you create the tunnel 
end-to-end which is basically the way BEET works. The policies created by HIP 
using tunnel mode would inner-addresses with prefix length of 128 bits which 
would mean that the packet received through the tunnel is destined to local 
host. In BEET you basically have a "tunnel" that is end-to-end (BEET just 
doesn't send the inner header on the wire). The HIP protocol is not able 
create a end-to-network tunnels as it is a end-to-end keying protocol. Using 
tunnel mode is pretty straight forward but you'll end up having the overhead 
of the IPv6 header (Our first linux implementation of HIP used tunnel mode 
instead of BEET mode).

  Regards,
    Jan

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 24 Aug 2006 19:53:38 +1200

> mode, other than in some WG discussions I've participated in).

But isn't it the case that a node can perfectly well run HIP and  
IPsec at the same time on different SPIs in any combination of  
modes?  In other words, mere support of HIP should have no effect on  
IPsec support.

There is little logical problem with running tunnel-mode between two  
HIP nodes using HIP as the keying/initialisation protocol, however  
this was somewhat contrary to the initial goals of HIP.   
Nevertheless, it should not be difficult.

Andrew

---

From: Jan Mikael Melen <[email-masked]>
Date: Thu, 24 Aug 2006 11:03:23 +0300

Hi Tom, Mark, and others

On inbound packet:

On outbound packet:

  Regards,
    Jan

---

From: Petri Jokela <[email-masked]>
Date: Fri, 25 Aug 2006 10:16:37 +0300

Mark Townsley wrote:
> 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.
> 

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

-- 
Petri Jokela				e-mail: [email-masked]
Research Scientist			phone:  +358 9 299 2413
Ericsson Research, NomadicLab		mobile: +358 44 299 2413

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 25 Aug 2006 07:30:40 -0700

> From: Andrew McGregor [mailto:[email-masked]] 
> Sent: Thursday, August 24, 2006 12:54 AM
> To: Henderson, Thomas R
> Cc: Mark Townsley; [email-masked]
> Subject: Re: [Hipsec] draft-ietf-hip-esp-03
> 

Yes, I misread the second part of the question as asking whether HIP
qualified as IPsec.  I agree with you.

mea culpa,
Tom

---

From: Mark Townsley <[email-masked]>
Date: Wed, 30 Aug 2006 18:11:00 +0200

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

---

From: Mark Townsley <[email-masked]>
Date: Wed, 30 Aug 2006 21:27:41 +0200

Thanks, Sam. Could you facilitate a secdir review?

- Mark

Sam Hartman wrote:
>>>>>> "Mark" == Mark Townsley <[email-masked]> writes:
>>>>>>             
>
>     Mark> It sounds like this addresses the concern in terms of "truth
>     Mark> in advertising" here, and I am very glad to see this as it
>     Mark> is certainly important. I wonder if the IPsec community will
>     Mark> have architectural issues with SPIs being attached to
>     Mark> specific processing above the IP stack (depending, I
>     Mark> suppose, on where you consider HIP, IP, and IPsec in
>     Mark> relation to one another). I remember somewhat similar cases
>     Mark> in the past causing serious heartburn within the IPsec
>     Mark> community.
>
> I actually saw a copy of the new section 3.4 before it was posted to
> the list (or at the same time).  I think the best thing to do at this
> point is to run it by the IPsec community either by asking for secdir
> reviews or by sending to the old ipsec list.
>
> I actually suspect you get more comments of the form "you said things
> the wrong way," than "you did things that must not be done.
>
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 30 Aug 2006 13:02:23 -0700

I have a few comments on this proposed text.

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

> described in this document should have a SP that is bound to 

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.

> data that has not come through the SA that was created by HIP.

I don't think the last sentence adds anything.

Regards,
Tom