Re: [Hipsec] BEET discussions

Robert Moskowitz <> Tue, 25 November 2008 22:08 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 4E3D228C1C5; Tue, 25 Nov 2008 14:08:14 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51C8D28C1C5 for <>; Tue, 25 Nov 2008 14:08:13 -0800 (PST)
X-Quarantine-ID: <WEKIphd8-CpZ>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER, Duplicate header field: "References"
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WEKIphd8-CpZ for <>; Tue, 25 Nov 2008 14:08:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3AC1028C1C4 for <>; Tue, 25 Nov 2008 14:08:12 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id mAPM6qE8022498 for <>; Tue, 25 Nov 2008 17:06:52 -0500
Received: from ( []) by (Scalix SMTP Relay via ESMTP; Tue, 25 Nov 2008 17:06:01 -0500 (EST)
Date: Tue, 25 Nov 2008 17:06:20 -0500
From: Robert Moskowitz <>
Message-ID: <>
In-Reply-To: <>
References: <>
References: <>
x-scalix-Hops: 1
User-Agent: Thunderbird (X11/20081120)
MIME-Version: 1.0
Content-Disposition: inline
Subject: Re: [Hipsec] BEET discussions
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Pekka Nikander wrote:
> 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.

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

> --Pekka
> On 25 Nov 2008, at 17:25, Robert Moskowitz wrote:
>> 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

Hipsec mailing list