Subject: [Hipsec] BEET vs. tunnel/HCoIPsec

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 21 Mar 2006 19:52:30 -0800

Pekka,
The mobike discussion on BEET was interesting to me because I became
aware of the header compression over IPsec tunnel mode work:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-hcoipsec-01.txt

As I have understood it, HIP has always assumed BEET mode, mainly for i)
efficiency reasons and ii) because SA selectors have been based on
destination addresses in IPsec.  Now, it seems that RFC 4303 Section 2.1
allows selectors to be based only on SPI (which seems to be a relaxation
from RFC 2406).  So perhaps item ii) is no longer relevant when using
currently defined IPsec.

So is the main remaining difference the efficiency of BEET mode vs.
(HCoIPsec) tunnel mode?  The possible advantages of HCoIPsec may be:
- do not have to reinvent header compression approaches that neglect IP
headers (it is claimed in the HC documents that most HC techniques
assume that they are working jointly on transport/IP header fields).
Plus, HCoIPsec should be more efficient than BEET alone.
- as far as BEET's present definition (I don't know whether this can be
fixed), fragmentation support may be cleaner/more secure for tunnel mode
(at least that is the point that Michael Richardson seemed to make at
the meeting).  I think he also argued that BEET was exposing additional
header information (possibly modifiable) that tunnel mode does not,
although I didn't catch the details.

The possible advantages of BEET over HCoIPsec might be:
- BEET seems to have (mostly) worked out how to handle different IP
address families in inner and outer headers, whereas I don't see that
capability in IPsec tunnel mode.
- I don't know whether HCoIPsec will be harder to operationally use than
BEET, leading to situation where most connections will run without it in
practice.

Do you see some other differences? 

Tom

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Mar 2006 16:24:33 +0100

In your previous mail you wrote:

   ii) because SA selectors have been based on destination addresses
   in IPsec.  Now, it seems that RFC 4303 Section 2.1 allows selectors
   to be based only on SPI (which seems to be a relaxation from RFC
   2406).  So perhaps item ii) is no longer relevant when using
   currently defined IPsec.
   
=> your use of the term "selector" here is fully wrong. I believe
you refer to the SA lookup for incomming packets: RFC 4301 proposes
the SPI only for unicast SAs.

=> I strongly disagree: this is in IPsec from the beginning.

Regards
   
[email-masked]

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 22 Mar 2006 11:16:33 -0600

Thomas,

> destination addresses in IPsec.

My stance here is slightly different.  To me, BEET is a way to  
implement the id/loc split within IPsec rather than outside of it.   
The benefit, from this point of view, is mainly security.  You gain  
assurance that incoming packets are indeed coming from the source  
HIT.  Sure, you could use tunnel mode for the same purposes but then  
you would need to have very strict policy of accepting only the  
certain source HIT from that tunnel.

I tried to illustrate this, perhaps foolishly, by stating this little  
security benefit in implementation terms.  In BEET, you overwrite the  
addresses with the information in the SPD.  With tunnelling, you  
verify that the inner addresses match with the information in the  
SPD.  Same end result, the difference being that the former  
configuration is more secure (less space for mistakes) and makes the  
inner header redundant.

> Do you see some other differences?

I tried to state above.

IMHO, we should have both.  They seem to be mostly orthogonal to me.   
When header compression is used with BEET, header compression can be  
applied to the transport header only, making it slightly more efficient.

Now, that all said, I could change my architect's hat to a hacker's  
hat, and then I would mostly agree with what you wrote.  In other  
words, the question in my mind is mostly architectural, and if you  
leave the architectural beauty aside, you *can* implement HIP, in an  
efficient way, just with inner header compression.

--Pekka

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 22 Mar 2006 18:59:35 -0800

> -----Original Message-----
> From: Francis Dupont [mailto:[email-masked]] 
> Sent: Wednesday, March 22, 2006 7:25 AM
> To: Henderson, Thomas R
> Cc: Pekka Nikander; HIP
> Subject: Re: [Hipsec] BEET vs. tunnel/HCoIPsec 
> 

Yes, you are right, I meant incoming SA lookup so should not have used
the term selector in that context.  But my point was that RFC 4303
language on this input processing differs from RFC 2401 Section 5.2.1,
where it was said that SA selection depended on the destination IP
address.

> => I strongly disagree: this is in IPsec from the beginning.

Thanks (also to Tero) for pointing this out.

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 22 Mar 2006 19:03:34 -0800

> IMHO, we should have both.  They seem to be mostly orthogonal 

Thanks for the clarification; I also see benefit to having both.

Tom

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Mar 2006 06:08:27 -0600

>=> I strongly disagree: this is in IPsec from the beginning.
I agree with Francis on this. I also implemented this. (This was a long
time ago -- I do not remember the details but I did not recall any
specific problems in the IPsec part. I do remember that we had
issues with IPsec policies matching NDP traffic, but that's a separate
issue and presumably applicable for both HIP and regular IPsec.)

--Jari