Re: ESP interfamily tunnel bug?

2007-04-19 Thread Diego Beltrami 

On Thu, 19 Apr 2007, Kazunori MIYAZAWA wrote:

 I'm using a machine and a dummy device.
 So I'm using loopback communication.
 Yes, the backtrace is correct.

 I thought you used loopback communication to test the modes
 because your configuration showed that the dummy device has
 some addresses and you did ping from the address to the other
 address.

 Is not right? Did you use two or more hosts?

If we understood you correctly, you are using a single machine? If yes, we
can repeat your problem too. There is something wrong with the
loopback, XFRM (and interfamily).

However, we were describing a different problem. We were using two
separate machines that were in different networks.


 I do not have enough environment to test today.
 I'll test it with a couple of machines tomorrow.

 Diego Beltrami wrote:
 Hi Kazunori,
 thanks for reply.

 In your backtrace I see that there are both input and output functions
 calls. Is
 it the right way?

 One more thing, were your two hosts you used located on the same network?
 In fact it seems that if the machines are on the same network, this bug
 doesn't
 manifest.

 Thanks,

 Diego


 Hello Diego,

 I tried to reproduce the bug. But I got a panic of the kernel :-
 I'm using current net-2.6.

 I suspect that some special routing for loopback is related
 because I checked with kdb and got the backtrace like

 fib_sync_down
 ipv6_rcv
 netif_receive_skb
 __mod_timer
 net_rx_action
 __do_softirq
 do_softirq
 local_bh_enable
 dev_queue_xmit
 neigh_resolve_output
 ip_output
 xfrm4_output_finish
 xfrm4_output
 ip_generic_getfrag
 ip6_push_pending_frames

 I think ip_rcv or some IPv4 function should be called between
 netif_receive_skb
 and ipv6_rcv.

 Anyway I could not classify the way to make a panic.
 I'll trace it.

 Thank you,

 Diego Beltrami wrote:
 Hi,

 we have discovered a routing related problem in ESP tunnel and beet mode.
 We don't know whether it is a bug in the XFRM, or just in the way the
 virtual addresses and the corresponding routes are set-up. We set up a
 dummy0 device for the virtual addresses:

 [EMAIL PROTECTED]:~# ip addr show dummy0
 5: dummy0: BROADCAST,NOARP,UP,1 mtu 1500 qdisc noqueue
  link/ether 92:09:fe:11:81:1b brd ff:ff:ff:ff:ff:ff
  inet6 2001:72:e6d3:1cf3:e11d:5bb0:b99:e85e/28 scope global
 valid_lft forever preferred_lft forever
  inet6 2001:74:32e0:df36:e862:3963:523e:dd7d/28 scope global
 valid_lft forever preferred_lft forever
  inet6 2001:73:d3a8:8723:d572:7549:7f2c:e590/28 scope global
 valid_lft forever preferred_lft forever
  inet6 2001:75:a2e6:aad6:e901:dd1c:ba95:e300/28 scope global
 valid_lft forever preferred_lft forever
  inet6 fe80::9009:feff:fe11:811b/64 scope link
 valid_lft forever preferred_lft forever

 And then we have routes for the virtual addresses:

 [EMAIL PROTECTED]:~# ip -6 route
 2001:72:e6d3:1cf3:e11d:5bb0:b99:e85e dev dummy0  metric 1024  expires
 21334305sec mtu 1500 advmss 1440 metric 10 4294967295
 2001:73:d3a8:8723:d572:7549:7f2c:e590 dev dummy0  metric 1024  expires
 21334305sec mtu 1500 advmss 1440 metric 10 4294967295
 2001:74:32e0:df36:e862:3963:523e:dd7d dev dummy0  metric 1024  expires
 21334305sec mtu 1500 advmss 1440 metric 10 4294967295
 2001:75:a2e6:aad6:e901:dd1c:ba95:e300 dev dummy0  metric 1024  expires
 21334305sec mtu 1500 advmss 1440 metric 10 4294967295
 2001:70::/28 dev dummy0  metric 256  expires 21334305sec mtu 1500 advmss
 1440 metric 10 4294967295
 fe80::/64 dev dummy0  metric 256  expires 21334305sec mtu 1500 advmss
 1440
 metric 10 4294967295
 ff00::/8 dev eth0  metric 256  expires 21325454sec mtu 1500 advmss 1440
 metric 10 4294967295
 ff00::/8 dev dummy0  metric 256  expires 21334305sec mtu 1500 advmss 1440
 metric 10 4294967295
 unreachable default dev lo  proto none  metric -1  error -101 metric 10
 255

 ...and set-up policies and associations. The virtual IPv6 addresses
 are inner and IPv4 addresses are outer addresses:

 [EMAIL PROTECTED]:~/projects/hipl--userspace--2.6# ip xfrm policy show
 src 2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/128 dst
 2001:74:32e0:df36:e862:3963:523e:dd7d/128
  dir in priority 0
  tmpl src c1a7:bb82:: dst c0a8:65::
  proto esp reqid 0 mode beet
 src 2001:74:32e0:df36:e862:3963:523e:dd7d/128 dst
 2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/128
  dir out priority 0
  tmpl src c0a8:65:: dst c1a7:bb82::
  proto esp reqid 0 mode beet

 [EMAIL PROTECTED]:~/projects/hipl--userspace--2.6# ip xfrm state show
 src 193.167.187.130 dst 192.168.0.101
  proto esp spi 0xf556c7c7 reqid 0 mode beet
  replay-window 0
  auth sha1 0xab327b944011c94a0c54a097b4752e23f377ff34
  enc aes 0x882a334830b1cd14b9e411ec37a4242f
  encap type espinudp-nonike sport 50500 dport 50500
addr 193.167.187.130
  sel src 2001:76:7d5a:88d7

ESP interfamily tunnel bug?

2007-04-18 Thread Diego Beltrami 
Hi,

we have discovered a routing related problem in ESP tunnel and beet mode.
We don't know whether it is a bug in the XFRM, or just in the way the
virtual addresses and the corresponding routes are set-up. We set up a
dummy0 device for the virtual addresses:

[EMAIL PROTECTED]:~# ip addr show dummy0
5: dummy0: BROADCAST,NOARP,UP,1 mtu 1500 qdisc noqueue
 link/ether 92:09:fe:11:81:1b brd ff:ff:ff:ff:ff:ff
 inet6 2001:72:e6d3:1cf3:e11d:5bb0:b99:e85e/28 scope global
valid_lft forever preferred_lft forever
 inet6 2001:74:32e0:df36:e862:3963:523e:dd7d/28 scope global
valid_lft forever preferred_lft forever
 inet6 2001:73:d3a8:8723:d572:7549:7f2c:e590/28 scope global
valid_lft forever preferred_lft forever
 inet6 2001:75:a2e6:aad6:e901:dd1c:ba95:e300/28 scope global
valid_lft forever preferred_lft forever
 inet6 fe80::9009:feff:fe11:811b/64 scope link
valid_lft forever preferred_lft forever

And then we have routes for the virtual addresses:

[EMAIL PROTECTED]:~# ip -6 route
2001:72:e6d3:1cf3:e11d:5bb0:b99:e85e dev dummy0  metric 1024  expires
21334305sec mtu 1500 advmss 1440 metric 10 4294967295
2001:73:d3a8:8723:d572:7549:7f2c:e590 dev dummy0  metric 1024  expires
21334305sec mtu 1500 advmss 1440 metric 10 4294967295
2001:74:32e0:df36:e862:3963:523e:dd7d dev dummy0  metric 1024  expires
21334305sec mtu 1500 advmss 1440 metric 10 4294967295
2001:75:a2e6:aad6:e901:dd1c:ba95:e300 dev dummy0  metric 1024  expires
21334305sec mtu 1500 advmss 1440 metric 10 4294967295
2001:70::/28 dev dummy0  metric 256  expires 21334305sec mtu 1500 advmss
1440 metric 10 4294967295
fe80::/64 dev dummy0  metric 256  expires 21334305sec mtu 1500 advmss 1440
metric 10 4294967295
ff00::/8 dev eth0  metric 256  expires 21325454sec mtu 1500 advmss 1440
metric 10 4294967295
ff00::/8 dev dummy0  metric 256  expires 21334305sec mtu 1500 advmss 1440
metric 10 4294967295
unreachable default dev lo  proto none  metric -1  error -101 metric 10
255

...and set-up policies and associations. The virtual IPv6 addresses
are inner and IPv4 addresses are outer addresses:

[EMAIL PROTECTED]:~/projects/hipl--userspace--2.6# ip xfrm policy show
src 2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/128 dst
2001:74:32e0:df36:e862:3963:523e:dd7d/128
 dir in priority 0
 tmpl src c1a7:bb82:: dst c0a8:65::
 proto esp reqid 0 mode beet
src 2001:74:32e0:df36:e862:3963:523e:dd7d/128 dst
2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/128
 dir out priority 0
 tmpl src c0a8:65:: dst c1a7:bb82::
 proto esp reqid 0 mode beet

[EMAIL PROTECTED]:~/projects/hipl--userspace--2.6# ip xfrm state show
src 193.167.187.130 dst 192.168.0.101
 proto esp spi 0xf556c7c7 reqid 0 mode beet
 replay-window 0
 auth sha1 0xab327b944011c94a0c54a097b4752e23f377ff34
 enc aes 0x882a334830b1cd14b9e411ec37a4242f
 encap type espinudp-nonike sport 50500 dport 50500
   addr 193.167.187.130
 sel src 2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/0
 dst 2001:74:32e0:df36:e862:3963:523e:dd7d/0
 src 192.168.0.101 dst 193.167.187.130
 proto esp spi 0x1663f3a4 reqid 0 mode beet
 replay-window 0
 auth sha1 0x9f07dabce4abf2ebfe45e247ede2cf15f9156a13
 enc aes 0xfc50593b9af6d296b042a16ca00bad20
 encap type espinudp-nonike
 sport 50500 dport 50500 addr 192.168.0.101
 sel src 2001:74:32e0:df36:e862:3963:523e:dd7d/0
 dst 2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/0

And then we try to ping6 the virtual address:

[EMAIL PROTECTED]:~/projects/hipl--userspace--2.6# ping6 -I
2001:0074:32e0:df36:e862:3963:523e:dd7d
2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15
PING
2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15(2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15)
from 2001:74:32e0:df36:e862:3963:523e:dd7d : 56 data bytes
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable

Tcpdump shows no traffic at the host. We can repeat the problem both with
tunnel and beet modes in 2.6.21-rc6 (and also in 2.6.17.14).

I have tried also ip rule stuff but it seems that it does not rule with
IPv6 :) It does help either to reduce the number of virtual addresses to a
single one. It is weird that the ESP actually works some combinations of
virtual addresses (4 of 16) in both directions, or works unidirectionally
on some and does not work at all on the rest. I verified the
unidirectional property using a simple UDP based application: sender xmits
UDP packet, receiver gets it ok, but cannot respond. So, the problem is in
the transmission of packets.

I traced the ENETUNREACH in the kernel side to here:

net/ipv4/route.c:ip_route_output_slow:
 if (fib_lookup(fl, res)) {
 
if (dev_out)
 dev_put(dev_out);
 err = -ENETUNREACH;

FIB lookup up is returning an error net/ipv4/fib_rules:

int fib_lookup(const struct flowi

Re: ESP interfamily tunnel bug?

2007-04-18 Thread Diego Beltrami 
Hi Kazunori,
thanks for reply.

In your backtrace I see that there are both input and output functions calls. Is
it the right way?

One more thing, were your two hosts you used located on the same network?
In fact it seems that if the machines are on the same network, this bug doesn't
manifest.

Thanks,

Diego


 Hello Diego,

 I tried to reproduce the bug. But I got a panic of the kernel :-
 I'm using current net-2.6.

 I suspect that some special routing for loopback is related
 because I checked with kdb and got the backtrace like

   fib_sync_down
   ipv6_rcv
   netif_receive_skb
   __mod_timer
   net_rx_action
   __do_softirq
   do_softirq
   local_bh_enable
   dev_queue_xmit
   neigh_resolve_output
   ip_output
   xfrm4_output_finish
   xfrm4_output
   ip_generic_getfrag
   ip6_push_pending_frames

 I think ip_rcv or some IPv4 function should be called between
 netif_receive_skb
 and ipv6_rcv.

 Anyway I could not classify the way to make a panic.
 I'll trace it.

 Thank you,

 Diego Beltrami wrote:
  Hi,
 
  we have discovered a routing related problem in ESP tunnel and beet mode.
  We don't know whether it is a bug in the XFRM, or just in the way the
  virtual addresses and the corresponding routes are set-up. We set up a
  dummy0 device for the virtual addresses:
 
  [EMAIL PROTECTED]:~# ip addr show dummy0
  5: dummy0: BROADCAST,NOARP,UP,1 mtu 1500 qdisc noqueue
   link/ether 92:09:fe:11:81:1b brd ff:ff:ff:ff:ff:ff
   inet6 2001:72:e6d3:1cf3:e11d:5bb0:b99:e85e/28 scope global
  valid_lft forever preferred_lft forever
   inet6 2001:74:32e0:df36:e862:3963:523e:dd7d/28 scope global
  valid_lft forever preferred_lft forever
   inet6 2001:73:d3a8:8723:d572:7549:7f2c:e590/28 scope global
  valid_lft forever preferred_lft forever
   inet6 2001:75:a2e6:aad6:e901:dd1c:ba95:e300/28 scope global
  valid_lft forever preferred_lft forever
   inet6 fe80::9009:feff:fe11:811b/64 scope link
  valid_lft forever preferred_lft forever
 
  And then we have routes for the virtual addresses:
 
  [EMAIL PROTECTED]:~# ip -6 route
  2001:72:e6d3:1cf3:e11d:5bb0:b99:e85e dev dummy0  metric 1024  expires
  21334305sec mtu 1500 advmss 1440 metric 10 4294967295
  2001:73:d3a8:8723:d572:7549:7f2c:e590 dev dummy0  metric 1024  expires
  21334305sec mtu 1500 advmss 1440 metric 10 4294967295
  2001:74:32e0:df36:e862:3963:523e:dd7d dev dummy0  metric 1024  expires
  21334305sec mtu 1500 advmss 1440 metric 10 4294967295
  2001:75:a2e6:aad6:e901:dd1c:ba95:e300 dev dummy0  metric 1024  expires
  21334305sec mtu 1500 advmss 1440 metric 10 4294967295
  2001:70::/28 dev dummy0  metric 256  expires 21334305sec mtu 1500 advmss
  1440 metric 10 4294967295
  fe80::/64 dev dummy0  metric 256  expires 21334305sec mtu 1500 advmss 1440
  metric 10 4294967295
  ff00::/8 dev eth0  metric 256  expires 21325454sec mtu 1500 advmss 1440
  metric 10 4294967295
  ff00::/8 dev dummy0  metric 256  expires 21334305sec mtu 1500 advmss 1440
  metric 10 4294967295
  unreachable default dev lo  proto none  metric -1  error -101 metric 10
  255
 
  ...and set-up policies and associations. The virtual IPv6 addresses
  are inner and IPv4 addresses are outer addresses:
 
  [EMAIL PROTECTED]:~/projects/hipl--userspace--2.6# ip xfrm policy show
  src 2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/128 dst
  2001:74:32e0:df36:e862:3963:523e:dd7d/128
   dir in priority 0
   tmpl src c1a7:bb82:: dst c0a8:65::
   proto esp reqid 0 mode beet
  src 2001:74:32e0:df36:e862:3963:523e:dd7d/128 dst
  2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/128
   dir out priority 0
   tmpl src c0a8:65:: dst c1a7:bb82::
   proto esp reqid 0 mode beet
 
  [EMAIL PROTECTED]:~/projects/hipl--userspace--2.6# ip xfrm state show
  src 193.167.187.130 dst 192.168.0.101
   proto esp spi 0xf556c7c7 reqid 0 mode beet
   replay-window 0
   auth sha1 0xab327b944011c94a0c54a097b4752e23f377ff34
   enc aes 0x882a334830b1cd14b9e411ec37a4242f
   encap type espinudp-nonike sport 50500 dport 50500
 addr 193.167.187.130
   sel src 2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/0
   dst 2001:74:32e0:df36:e862:3963:523e:dd7d/0
   src 192.168.0.101 dst 193.167.187.130
   proto esp spi 0x1663f3a4 reqid 0 mode beet
   replay-window 0
   auth sha1 0x9f07dabce4abf2ebfe45e247ede2cf15f9156a13
   enc aes 0xfc50593b9af6d296b042a16ca00bad20
   encap type espinudp-nonike
   sport 50500 dport 50500 addr 192.168.0.101
   sel src 2001:74:32e0:df36:e862:3963:523e:dd7d/0
   dst 2001:76:7d5a:88d7:51af:cdd1:6bf5:3d15/0
 
  And then we try to ping6 the virtual address:
 
  [EMAIL PROTECTED]:~/projects/hipl--userspace--2.6# ping6 -I
  2001:0074:32e0:df36:e862:3963:523e:dd7d
  2001:76:7d5a:88d7:51af:cdd1:6bf5

Re: [PATCH]:[XFRM] BEET mode

2006-09-19 Thread Diego Beltrami 
Quoting Miika Komu [EMAIL PROTECTED]:

 On Tue, 19 Sep 2006, Miika Komu wrote:

  Ah, forgot to add new files to version control, sorry. My bad...

 The last patch I sent should be fine.


Yes, this patch taken from the mail works just fine.



-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH]:[XFRM] BEET mode

2006-09-16 Thread Diego Beltrami 
The patch which introduces the BEET mode and which previously was sent to this 
mailing list is valid also for
http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.19.git;a=summary
branch.
However there are probably some errors in attaching inline the patch to the 
mail.
I retry to reattach it. In any case, if there would be some errors, the same 
patch can be found at the following URL and it works just fine:

http://infrahip.hiit.fi/beet/tmp/simple-beet-ph-patch-2.6.18

For those who haven't been following this discussion, the patch introduces the 
BEET mode (Bound End-to-End Tunnel) as specified by the ietf draft at the 
following link:

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

Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
Signed-off-by: Miika Komu [EMAIL PROTECTED]
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: Abhinav Pathak [EMAIL PROTECTED]
Signed-off-by: Jeff Ahrenholz [EMAIL PROTECTED]

Thanks,
--
Diego Beltrami


diff --git a/include/linux/in.h b/include/linux/in.h
index bcaca83..f1ae3cc 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -40,6 +40,7 @@ enum {

   IPPROTO_ESP = 50,/* Encapsulation Security Payload protocol */
   IPPROTO_AH = 51, /* Authentication Header protocol   */
+  IPPROTO_BEETPH = 94,/* IP option pseudo header for BEET */
   IPPROTO_PIM= 103,/* Protocol Independent Multicast   
*/

   IPPROTO_COMP   = 108,/* Compression Header protocol */
diff --git a/include/linux/ip.h b/include/linux/ip.h
index 2f46001..7a3aee8 100644
--- a/include/linux/ip.h
+++ b/include/linux/ip.h
@@ -80,6 +80,8 @@
 #defineIPOPT_TS_TSANDADDR  1   /* timestamps and 
addresses */
 #defineIPOPT_TS_PRESPEC3   /* specified modules 
only */

+#define IPV4_BEET_PHMAXLEN 8
+
 struct iphdr {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
__u8ihl:4,
@@ -123,4 +125,11 @@ struct ip_comp_hdr {
__u16 cpi;
 };

+struct ip_beet_phdr {
+   __u8 nexthdr;
+   __u8 hdrlen;
+   __u8 padlen;
+   __u8 reserved;
+};
+
 #endif /* _LINUX_IP_H */
diff --git a/include/linux/ipsec.h b/include/linux/ipsec.h
index d3c5276..d17a630 100644
--- a/include/linux/ipsec.h
+++ b/include/linux/ipsec.h
@@ -12,7 +12,8 @@
 enum {
IPSEC_MODE_ANY  = 0,/* We do not support this for SA */
IPSEC_MODE_TRANSPORT= 1,
-   IPSEC_MODE_TUNNEL   = 2
+   IPSEC_MODE_TUNNEL   = 2,
+   IPSEC_MODE_BEET = 3
 };

 enum {
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 14ecd19..a745cb3 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -129,7 +129,8 @@ enum
 #define XFRM_MODE_TUNNEL 1
 #define XFRM_MODE_ROUTEOPTIMIZATION 2
 #define XFRM_MODE_IN_TRIGGER 3
-#define XFRM_MODE_MAX 4
+#define XFRM_MODE_BEET 4
+#define XFRM_MODE_MAX 5

 /* Netlink configuration messages.  */
 enum {
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 90f9136..c5e3b17 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -433,6 +433,15 @@ config INET_XFRM_MODE_TUNNEL

  If unsure, say Y.

+config INET_XFRM_MODE_BEET
+   tristate IP: IPsec BEET mode
+   default y
+   select XFRM
+   ---help---
+ Support for IPsec BEET mode.
+
+ If unsure, say Y.
+
 config INET_DIAG
tristate INET: socket monitoring interface
default y
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index f66049e..15645c5 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_INET_AH) += ah4.o
 obj-$(CONFIG_INET_ESP) += esp4.o
 obj-$(CONFIG_INET_IPCOMP) += ipcomp.o
 obj-$(CONFIG_INET_XFRM_TUNNEL) += xfrm4_tunnel.o
+obj-$(CONFIG_INET_XFRM_MODE_BEET) += xfrm4_mode_beet.o
 obj-$(CONFIG_INET_TUNNEL) += tunnel4.o
 obj-$(CONFIG_INET_XFRM_MODE_TRANSPORT) += xfrm4_mode_transport.o
 obj-$(CONFIG_INET_XFRM_MODE_TUNNEL) += xfrm4_mode_tunnel.o
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 9628de9..c846f13 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -241,7 +241,8 @@ static int esp_input(struct xfrm_state *
 *as per draft-ietf-ipsec-udp-encaps-06,
 *section 3.1.2
 */
-   if (x-props.mode == XFRM_MODE_TRANSPORT)
+   if (x-props.mode == XFRM_MODE_TRANSPORT ||
+   x-props.mode == XFRM_MODE_BEET)
skb-ip_summed = CHECKSUM_UNNECESSARY;
}

@@ -259,17 +260,28 @@ static u32 esp4_get_max_size(struct xfrm
 {
struct esp_data *esp = x-data;
u32 blksize = ALIGN(crypto_tfm_alg_blocksize(esp-conf.tfm), 4);
+   int enclen = 0;

-   if (x-props.mode == XFRM_MODE_TUNNEL) {
-   mtu = ALIGN(mtu + 2, blksize);
-   } else {
-   /* The worst case. */
+   switch (x-props.mode) {
+   case XFRM_MODE_TUNNEL:
+   mtu = ALIGN(mtu +2, blksize

Re: [PATCH]:[XFRM] BEET mode

2006-09-14 Thread Diego Beltrami 

 I suppose that this applies to Dave's netdev git tree?
 That would explain why I get lots of patch errors when I try
 to apply it to 2.6.18-rc7...

Actually we made the patch against linux/kernel/git/acme/net-2.6.19.git

is that the wrong branch?

--
Diego

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH]:[XFRM] BEET mode

2006-09-13 Thread Diego Beltrami 
Hi all,

here you can find the patch rebased to the current tree net-2.6.19 which
introduces the BEET mode (Bound End-to-End Tunnel) as specified by the ietf
draft at the following link:

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

A BEET mode Security Associations records two pairs of IP addresses, called
inner addresses and outer addresses.  The inner addresses are what the
applications see.  The outer addresses are what appear on the wire.

The presented BEET mode allows for transformation having inner family equal to
outer family.

Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
Signed-off-by: Miika Komu [EMAIL PROTECTED]
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: Abhinav Pathak [EMAIL PROTECTED]
Signed-off-by: Jeff Ahrenholz [EMAIL PROTECTED]

--
Diego Beltrami

diff --git a/include/linux/in.h b/include/linux/in.h
index bcaca83..f1ae3cc 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -40,6 +40,7 @@ enum {

   IPPROTO_ESP = 50,/* Encapsulation Security Payload protocol */
   IPPROTO_AH = 51, /* Authentication Header protocol   */
+  IPPROTO_BEETPH = 94,/* IP option pseudo header for BEET */
   IPPROTO_PIM= 103,/* Protocol Independent Multicast   
*/

   IPPROTO_COMP   = 108,/* Compression Header protocol */
diff --git a/include/linux/ip.h b/include/linux/ip.h
index 2f46001..7a3aee8 100644
--- a/include/linux/ip.h
+++ b/include/linux/ip.h
@@ -80,6 +80,8 @@
 #defineIPOPT_TS_TSANDADDR  1   /* timestamps and 
addresses */
 #defineIPOPT_TS_PRESPEC3   /* specified modules 
only */

+#define IPV4_BEET_PHMAXLEN 8
+
 struct iphdr {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
__u8ihl:4,
@@ -123,4 +125,11 @@ struct ip_comp_hdr {
__u16 cpi;
 };

+struct ip_beet_phdr {
+   __u8 nexthdr;
+   __u8 hdrlen;
+   __u8 padlen;
+   __u8 reserved;
+};
+
 #endif /* _LINUX_IP_H */
diff --git a/include/linux/ipsec.h b/include/linux/ipsec.h
index d3c5276..d17a630 100644
--- a/include/linux/ipsec.h
+++ b/include/linux/ipsec.h
@@ -12,7 +12,8 @@
 enum {
IPSEC_MODE_ANY  = 0,/* We do not support this for SA */
IPSEC_MODE_TRANSPORT= 1,
-   IPSEC_MODE_TUNNEL   = 2
+   IPSEC_MODE_TUNNEL   = 2,
+   IPSEC_MODE_BEET = 3
 };

 enum {
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 14ecd19..a745cb3 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -129,7 +129,8 @@ enum
 #define XFRM_MODE_TUNNEL 1
 #define XFRM_MODE_ROUTEOPTIMIZATION 2
 #define XFRM_MODE_IN_TRIGGER 3
-#define XFRM_MODE_MAX 4
+#define XFRM_MODE_BEET 4
+#define XFRM_MODE_MAX 5

 /* Netlink configuration messages.  */
 enum {
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 90f9136..c5e3b17 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -433,6 +433,15 @@ config INET_XFRM_MODE_TUNNEL

  If unsure, say Y.

+config INET_XFRM_MODE_BEET
+   tristate IP: IPsec BEET mode
+   default y
+   select XFRM
+   ---help---
+ Support for IPsec BEET mode.
+
+ If unsure, say Y.
+
 config INET_DIAG
tristate INET: socket monitoring interface
default y
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index f66049e..15645c5 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_INET_AH) += ah4.o
 obj-$(CONFIG_INET_ESP) += esp4.o
 obj-$(CONFIG_INET_IPCOMP) += ipcomp.o
 obj-$(CONFIG_INET_XFRM_TUNNEL) += xfrm4_tunnel.o
+obj-$(CONFIG_INET_XFRM_MODE_BEET) += xfrm4_mode_beet.o
 obj-$(CONFIG_INET_TUNNEL) += tunnel4.o
 obj-$(CONFIG_INET_XFRM_MODE_TRANSPORT) += xfrm4_mode_transport.o
 obj-$(CONFIG_INET_XFRM_MODE_TUNNEL) += xfrm4_mode_tunnel.o
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 9628de9..c846f13 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -241,7 +241,8 @@ static int esp_input(struct xfrm_state *
 *as per draft-ietf-ipsec-udp-encaps-06,
 *section 3.1.2
 */
-   if (x-props.mode == XFRM_MODE_TRANSPORT)
+   if (x-props.mode == XFRM_MODE_TRANSPORT ||
+   x-props.mode == XFRM_MODE_BEET)
skb-ip_summed = CHECKSUM_UNNECESSARY;
}

@@ -259,17 +260,28 @@ static u32 esp4_get_max_size(struct xfrm
 {
struct esp_data *esp = x-data;
u32 blksize = ALIGN(crypto_tfm_alg_blocksize(esp-conf.tfm), 4);
+   int enclen = 0;

-   if (x-props.mode == XFRM_MODE_TUNNEL) {
-   mtu = ALIGN(mtu + 2, blksize);
-   } else {
-   /* The worst case. */
+   switch (x-props.mode) {
+   case XFRM_MODE_TUNNEL:
+   mtu = ALIGN(mtu +2, blksize);
+   break;
+   default:
+   case XFRM_MODE_TRANSPORT:
+   /* The worst case */
mtu = ALIGN(mtu + 2, 4) + blksize - 4

[PATCH]:[XFRM] BEET mode

2006-09-10 Thread Diego Beltrami 
Hi,

as part of this email you can find a patch which introduces the BEET mode (Bound
End-to-End Tunnel) as specified by the ietf draft at the following link:

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

A BEET mode Security Associations records two pairs of IP addresses, called
inner addresses and outer addresses.  The inner addresses are what the
applications see.  The outer addresses are what appear on the wire.

The presented BEET mode allows for transformation having inner family equal to
outer family.

Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
   Miika Komu [EMAIL PROTECTED]
   Herbert Xu [EMAIL PROTECTED]
   Abhinav Pathak [EMAIL PROTECTED]
   Jeff Ahrenholz [EMAIL PROTECTED]

--
Diego Beltrami


diff --git a/include/linux/in.h b/include/linux/in.h
index 94f557f..9290d99 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -40,6 +40,7 @@ enum {

   IPPROTO_ESP = 50,/* Encapsulation Security Payload protocol */
   IPPROTO_AH = 51, /* Authentication Header protocol   */
+  IPPROTO_BEETPH = 94,/* IP option pseudo header for BEET */
   IPPROTO_PIM= 103,/* Protocol Independent Multicast   
*/

   IPPROTO_COMP   = 108,/* Compression Header protocol */
diff --git a/include/linux/ip.h b/include/linux/ip.h
index 4b55cf1..e4d8a39 100644
--- a/include/linux/ip.h
+++ b/include/linux/ip.h
@@ -79,6 +79,8 @@
 #defineIPOPT_TS_TSANDADDR  1   /* timestamps and 
addresses */
 #defineIPOPT_TS_PRESPEC3   /* specified modules 
only */

+#define IPV4_BEET_PHMAXLEN 8
+
 struct iphdr {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
__u8ihl:4,
@@ -122,4 +124,11 @@ struct ip_comp_hdr {
__u16 cpi;
 };

+struct ip_beet_phdr {
+   __u8 nexthdr;
+   __u8 hdrlen;
+   __u8 padlen;
+   __u8 reserved;
+};
+
 #endif /* _LINUX_IP_H */
diff --git a/include/linux/ipsec.h b/include/linux/ipsec.h
index d3c5276..d17a630 100644
--- a/include/linux/ipsec.h
+++ b/include/linux/ipsec.h
@@ -12,7 +12,8 @@
 enum {
IPSEC_MODE_ANY  = 0,/* We do not support this for SA */
IPSEC_MODE_TRANSPORT= 1,
-   IPSEC_MODE_TUNNEL   = 2
+   IPSEC_MODE_TUNNEL   = 2,
+   IPSEC_MODE_BEET = 3
 };

 enum {
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 46a15c7..6a616de 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -120,7 +120,8 @@ enum

 #define XFRM_MODE_TRANSPORT 0
 #define XFRM_MODE_TUNNEL 1
-#define XFRM_MODE_MAX 2
+#define XFRM_MODE_BEET 2
+#define XFRM_MODE_MAX 3

 /* Netlink configuration messages.  */
 enum {
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 8514106..02c5ff7 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -432,6 +432,15 @@ config INET_XFRM_MODE_TUNNEL

  If unsure, say Y.

+config INET_XFRM_MODE_BEET
+   tristate IP: IPsec BEET mode
+   default y
+   select XFRM
+   ---help---
+ Support for IPsec BEET mode.
+
+ If unsure, say Y.
+
 config INET_DIAG
tristate INET: socket monitoring interface
default y
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index 4878fc5..ad22492 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_INET_XFRM_TUNNEL) += xfrm4_
 obj-$(CONFIG_INET_TUNNEL) += tunnel4.o
 obj-$(CONFIG_INET_XFRM_MODE_TRANSPORT) += xfrm4_mode_transport.o
 obj-$(CONFIG_INET_XFRM_MODE_TUNNEL) += xfrm4_mode_tunnel.o
+obj-$(CONFIG_INET_XFRM_MODE_BEET) += xfrm4_mode_beet.o
 obj-$(CONFIG_IP_PNP) += ipconfig.o
 obj-$(CONFIG_IP_ROUTE_MULTIPATH_RR) += multipath_rr.o
 obj-$(CONFIG_IP_ROUTE_MULTIPATH_RANDOM) += multipath_random.o
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 1366bc6..9d6f0e7 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -253,7 +253,7 @@ static int ah_init_state(struct xfrm_sta
goto error;

x-props.header_len = XFRM_ALIGN8(sizeof(struct ip_auth_hdr) +
ahp-icv_trunc_len);
-   if (x-props.mode)
+   if (x-props.mode == XFRM_MODE_TUNNEL)
x-props.header_len += sizeof(struct iphdr);
x-data = ahp;

diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index fc2f8ce..76722e1 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -237,7 +237,8 @@ static int esp_input(struct xfrm_state *
 *as per draft-ietf-ipsec-udp-encaps-06,
 *section 3.1.2
 */
-   if (!x-props.mode)
+   if (x-props.mode == XFRM_MODE_TUNNEL ||
+   x-props.mode == XFRM_MODE_BEET )
skb-ip_summed = CHECKSUM_UNNECESSARY;
}

@@ -255,17 +256,28 @@ static u32 esp4_get_max_size(struct xfrm
 {
struct esp_data *esp = x-data;
u32 blksize = ALIGN(crypto_tfm_alg_blocksize(esp-conf.tfm), 4);
+   int enclen = 0;

-   if (x-props.mode

Re: [2/4] [IPSEC] xfrm: Abstract out encapsulation modes

2006-05-27 Thread Diego Beltrami 
Quoting Herbert Xu [EMAIL PROTECTED]:

 [IPSEC] xfrm: Abstract out encapsulation modes

 This patch adds the structure xfrm_mode.  It is meant to represent
 the operations carried out by transport/tunnel modes.

 By doing this we allow additional encapsulation modes to be added
 without clogging up the xfrm_input/xfrm_output paths.

 Candidate modes include 4-to-6 tunnel mode, 6-to-4 tunnel mode, and
 BEET modes.

Herbert,
this is a very good patch, indeed!
Well done!

--
Diego


-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html