Re: [Hipsec] [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux

Re: [Hipsec] [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux

[Diego Beltrami]

Folks,
I'm sorry but the sent patch included in the email seems to be broken.
Please, use the URL 
http://hipl.hiit.fi/beet/beet-patch-v1.0-2.6.12.2

Sincerely


> Hi folks,
> 
> we have been working for three months to implement a new IPsec mode,
> the "BEET" mode, for Linux. Below is a link to the BEET specification
> and
> the abstract:
> 
> http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt
> 
> Abstract
> 
>    This document specifies a new mode, called Bound End-to-End Tunnel
>    (BEET) mode, for IPsec ESP.  The new mode augments the existing ESP
>    tunnel and transport modes.  For end-to-end tunnels, the new mode
>    provides limited tunnel mode semantics without the regular tunnel
>    mode overhead.  The mode is intended to support new uses of ESP,
>    including mobility and multi-address multi-homing.
> 
> The BEET mode is required by the Host Identity Protocol (HIP), which
> provides authenticated Diffie-Hellman for end-hosts, as well as
> mobility and multihoming support. The BEET mode is also useful for
> other similar protocols being developed at the IETF.
> 
> Ericsson has already developed a BEET patch for *BSD. Our patch
> provides the similar functionality, but using the XFRM architecture.
> The patch is included at the end of this email and also at the following
> URL:
> http://hipl.hiit.fi/beet/beet-patch-v1.0-2.6.12.2
> 
> We have made some testing in order to assure the quality of the
> patch. All the tests passed, and below is a list of them:
> 
> * Does not break transport and tunnel mode (with CONFIG_XFRM_BEET
> on/off)
> * All inner-outer combinations with varying test applications:
>   ICMP, ICMPv6, FTP, SSH, nc, nc6
> * Works with fragmented packets
> * Interoperability with HIPL
> * Real machines, virtual machines (vmware)
> * Tested with long data streams
> 
> The BEET development team:
> 
> * Abhinav Pathak <abpathak@iitk.ac.in> (InfraHIP/HIIT)
> * Diego Beltrami <diego.beltrami@hiit.fi> (InfraHIP/HIIT)
> * Kristian Slavov <kristian.slavov@nomadiclab.com> (Ericsson)
> * Miika Komu <miika@iki.fi> (InfraHIP/HIIT)
> * Jeff Ahrenholz <jeffrey.m.ahrenholz@boeing.com> (Boeing)
> 
> On the behalf of the BEET development team,
> 
> Signed-off-by: Diego Beltrami <diego.beltrami@hiit.fi>
> 
> 
> 

Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux

[Miika Komu]

> Ericsson has already developed a BEET patch for *BSD. Our patch
> provides the similar functionality, but using the XFRM architecture.
> The patch is included at the end of this email and also at the following
> URL:
> http://hipl.hiit.fi/beet/beet-patch-v1.0-2.6.12.2

We added more files to the same directory that are helpful for testing the
patch. There is a patch for setkey which enables you to configure security
associations manually. Also, there is a simple script that can be used for
quick testing of ping over BEET ESP security associations.

http://hipl.hiit.fi/beet/ipsec-tools-0.5.1-patch-beet
http://hipl.hiit.fi/beet/run-beet.sh

Looking forward for feedback,
-- 
Miika Komu              miika@iki.fi          http://www.iki.fi/miika/

Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux

[Herbert Xu]

Diego Beltrami <diego.beltrami@hiit.fi> wrote:
> 
> we have been working for three months to implement a new IPsec mode,
> the "BEET" mode, for Linux. Below is a link to the BEET specification
> and
> the abstract:
> 
> http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt

Thanks for the patch guys, this is really interesting.

> extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type);
> diff -urN linux-2.6.12.2/net/ipv4/esp4.c
> linux-beet-2.6.12.2/net/ipv4/esp4.c
> --- linux-2.6.12.2/net/ipv4/esp4.c      2005-06-30 02:00:53.000000000 +0300
> +++ linux-beet-2.6.12.2/net/ipv4/esp4.c 2005-07-25 14:39:11.000000000

Although the document only talks about ESP, as far as I can see
the encapsulation can be applied to AH/IPComp just as well.
So how about moving this stuff to the generic xfrm_input/xfrm_output
functions?

Also, if you're going to do cross-family transforms, it should be
done for both BEET and plain tunnel-mode.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [hipl-users] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux

[Diego Beltrami]

> Diego Beltrami <diego.beltrami@hiit.fi> wrote:
> > 
> > we have been working for three months to implement a new IPsec mode,
> > the "BEET" mode, for Linux. Below is a link to the BEET specification
> > and
> > the abstract:
> > 
> > http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt
> 
> Thanks for the patch guys, this is really interesting.

Thanks Herbert for your feedback!


> > extern int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type);
> > diff -urN linux-2.6.12.2/net/ipv4/esp4.c
> > linux-beet-2.6.12.2/net/ipv4/esp4.c
> > --- linux-2.6.12.2/net/ipv4/esp4.c      2005-06-30 02:00:53.000000000 +0300
> > +++ linux-beet-2.6.12.2/net/ipv4/esp4.c 2005-07-25 14:39:11.000000000
> 
> Although the document only talks about ESP, as far as I can see
> the encapsulation can be applied to AH/IPComp just as well.
> So how about moving this stuff to the generic xfrm_input/xfrm_output
> functions?

The BEET code is already present in xfrm_input/xfrm_output functions and
it applies ESP encapsulation merely because of SA and SP set by means
setkey. As a consequence, if SA and SP are correctly set for AH the flow
goes through the AH functions. 

The modifications in the ESP functions are due to the hybrid cases when
Inner and Outer address families are different; in those cases the
values returned by espX functions are not coherent.

I tried to change SA and SP so that AH is used and the flow correctly
goes through AH functions but the problem has been revealed to be
something else. In particular, it seems that the AH functions deal with
the pointers contained in skb (skb->data, skb->nh, skb->h etc) in a
slightly different way than ESP functions. (Can anyone say more?)

Surely BEET will work also for AH with minor changes, even though we
only tried the ESP encapsulation.
This will require some time to inspect and analyze the exact situation.

In any case, as a result, I would say the code is already generic
itself.


On the other hand I don't know about IPComp, so I wouldn't say anything.
Hence if You could please give some hints, they will be more than
appreciated.

> 
> Also, if you're going to do cross-family transforms, it should be
> done for both BEET and plain tunnel-mode.

Potentially it could be possible also for plain tunnel-mode: this will
require further analysis.

For further discussion and advice, please give feedback.
Thank You very much!

Cheers,

--Diego

Re: [Infrahip] Re: [hipl-users] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux

[Pekka Nikander]

> Surely BEET will work also for AH with minor changes, even though we
> only tried the ESP encapsulation.

I wouldn't be so sure.  IIRC, tunnel mode is not specified for AH but  
for ESP only.  Consequently, defining BEET mode for AH might be  
pretty tricky.  OTOH, I don't know the linux IPsec implementation so  
that it might be possible to make BEET to "work" for AH, for some  
value of "work", but it probably would require some careful thinking  
to define the exact semantics, like what addresses (inner or outer)  
are covered by the AH integrity protection, what does the integrity  
protection really assert, etc.

--Pekka

Re: [Infrahip] Re: [hipl-users] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux

[Herbert Xu]

On Fri, Jul 29, 2005 at 05:45:24PM +0200, Pekka Nikander wrote:
> >Surely BEET will work also for AH with minor changes, even though we
> >only tried the ESP encapsulation.
> 
> I wouldn't be so sure.  IIRC, tunnel mode is not specified for AH but  
> for ESP only.  Consequently, defining BEET mode for AH might be  

Well plain tunnel mode certainly is specified for AH as well as IPComp.
But you're right the semantics of BEET mode for AH needs to be thought
out.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux

[Diego Beltrami]

> On Fri, Jul 29, 2005 at 05:45:24PM +0200, Pekka Nikander wrote:
> > >Surely BEET will work also for AH with minor changes, even though we
> > >only tried the ESP encapsulation.
> > 
> > I wouldn't be so sure.  IIRC, tunnel mode is not specified for AH but  
> > for ESP only.  Consequently, defining BEET mode for AH might be  
> 
> Well plain tunnel mode certainly is specified for AH as well as IPComp.
> But you're right the semantics of BEET mode for AH needs to be thought
> out.
> 

The Linux patch which has been presented (see URL: 
http://infrahip.hiit.fi/beet/beet-patch-v1.0-2.6.12.2 ), has been
developed based upon the design given by the draft

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

As a result BEET patch considers the ESP encapsulation as it has been
designed.

OTOH we believe the implementation is usable more or less as it is now
for AH and perhaps IPComp in the future. But, as already mentioned both
by Pekka and Herbert, this would need more thinking and designing.

The implementation is flexible enough to finetune once the semantics for
similar optimizations have been considered for AH and IPComp.

--Diego

Re: [hipl-users] Re: [PATCH 2.6.12.2] XFRM: BEET IPsec mode for Linux

[Herbert Xu]

Diego Beltrami <diego.beltrami@hiit.fi> wrote:
> 
> The modifications in the ESP functions are due to the hybrid cases when
> Inner and Outer address families are different; in those cases the
> values returned by espX functions are not coherent.

I see.  However, this is really a consequence of us not implementing
interfamily transforms for plain old tunnel mode.  Had we implemented
that, it would be a piece of cake to extend this to BEET without
touching ESP.

>> Also, if you're going to do cross-family transforms, it should be
>> done for both BEET and plain tunnel-mode.
> 
> Potentially it could be possible also for plain tunnel-mode: this will
> require further analysis.

It definitely does need further analysis even for BEET mode.  The rcv
path for interfamily transforms is straightforward since we pass through
netif_rx.  However, on the outbound path things aren't that simple.

I suggest that you remove the interfamily support for the initial merge
of the BEET implementation.  We can then readd it for both plain tunnel
and BEET mode.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt