Subject: [Hipsec] BEET discussions

From: Robert Moskowitz <[email-masked]>
Date: Tue, 25 Nov 2008 10:25:59 -0500

Has BEET mode been discussed outside of the HIP list?

In my work last week to get HIP moving to Standards track, it became 
clear that BEET ESP will be a part of this and it will need to be 
reviewed by IPsec-centric people.  Tim Polk already had Sheila Frankel 
looking at it, and Paul Hoffman acknowledged that he would also have to 
review it.

One thing that became evident is that the why of BEET mode is needed to 
be clearly stated.  For example I am missing the explaination that in 
BEET mode, the SA survives changes to the outer IP addresses.

Also the semantics are related to tunnel mode with a nod to tranport mode.

I am still trying to get a feel for the ID.  It still feels like the 
placement of BEET mode with respect to the other modes is defused over 
the document and not well delineated in the beginning.  Not only what 
BEET adds, but what problems occur when you try to do BEET semantics 
with tunnel or transport instead.

I do want to say that I applaud the efforts that went into creating BEET 
mode, developing the current draft, and getting it into the 2.6.27 
kernel (of course I want it in the 2.6.18 kernel as well without 
patching....).

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

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 25 Nov 2008 17:48:11 +0200

BEET mode was discussed in its early dais, and was basically rejected  
by the IPsec folks (mainly Steve K) then, mainly due to not being any  
"need" for it, or just not wanting even to consider a new mode to  
IPsec.  Then some people claimed that it would be better to simply  
used inner header compression instead.

--Pekka

On 25 Nov 2008, at 17:25, Robert Moskowitz wrote:

> reviewed by IPsec-centric people.  Tim Polk already had Sheila  
> Frankel looking at it, and Paul Hoffman acknowledged that he would  
> also have to review it.
>
> One thing that became evident is that the why of BEET mode is needed  
> to be clearly stated.  For example I am missing the explaination  
> that in BEET mode, the SA survives changes to the outer IP addresses.
>
> placement of BEET mode with respect to the other modes is defused  
> over the document and not well delineated in the beginning.  Not  
> only what BEET adds, but what problems occur when you try to do BEET  
> semantics with tunnel or transport instead.
>
> I do want to say that I applaud the efforts that went into creating  
> BEET mode, developing the current draft, and getting it into the  
> 2.6.27 kernel (of course I want it in the 2.6.18 kernel as well  
> without patching....).
>
>

---

From: Miika Komu <[email-masked]>
Date: Tue, 25 Nov 2008 17:54:07 +0200

Pekka Nikander wrote:

Hi,

times have also changed since then and there are three interoperable 
BEET implementations now (in linux 2.6.27 kernel, in BSD and the 
userspace BEET). Could you or Jan resubmit the draft to the IETF archives?

> BEET mode was discussed in its early dais, and was basically rejected by 
> the IPsec folks (mainly Steve K) then, mainly due to not being any 
> IPsec.  Then some people claimed that it would be better to simply used 
> inner header compression instead.
> 
> --Pekka
> 
>> looking at it, and Paul Hoffman acknowledged that he would also have 
>> to review it.
>>
>> to be clearly stated.  For example I am missing the explaination that 
>> in BEET mode, the SA survives changes to the outer IP addresses.
>>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 25 Nov 2008 17:06:01 -0500

> userspace BEET). Could you or Jan resubmit the draft to the IETF 

Draft 9 is already out there. They did this for me back after I visited
Helsinki.

>>> over the document and not well delineated in the beginning. Not only 
>>> what BEET adds, but what problems occur when you try to do BEET

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 25 Nov 2008 17:06:20 -0500

> inner header compression instead.

So then it is valuable to capture in the draft a comparison of BEET to
Tunnel with header compression?

The 'need' can be clearer. I am almost thinking of a WHY? section after
the introduction. It would restate things covered elsewhere, but it
would draw a reader in and present the case for BEET compared to
transport and wrapping the SA with internal address semantics or tunnel
with internal header compression, and both with zeroing out the outer
addresses to gain outer address independence. (I suspect there is more,
but to me these seem to be the 'high' points).

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 26 Nov 2008 07:49:15 -0500

>> used inner header compression instead.

I have gotten a few emails asking for where the current draft is:

http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-09.txt