[Ipsec-tools-devel] Re: [design] ipcomp between fsw-2.04 and racoon

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Just for record: FreeBSD 5.2 has the same behaviour as Linux 2.6

ipsec_tunnel_hard_header: skb->dev=3Dipsec0 dev=3Dipsec0.
ipsec_tunnel_hard_header: Revectored 0p00000000->0pc3725264 len=3D10028 =
type=3D2048 dev=3Dipsec0->eth0 dev_addr=3D00:60:97:d8:e4:d2 =
ip=3D0a010164->0a01020a
ipsec_xmit_strip_hard_header: >>> skb->len=3D10042 hard_header_len:14 =
00:60:97:d8:e4:d2:00:60:97:d8:e4:d2:08:00=20
   IP: ihl:20 ver:4 tos:0 tlen:10028 id:165 frag_off:0 ttl:127 proto:1 =
(ICMP) chk:64700 saddr:10.1.1.100 daddr:10.1.2.10 type:code=3D8:0
ipsec_xmit_strip_hard_header: Original head,tailroom: 18,20
ipsec_findroute: 10.1.1.100->10.1.2.10
rj_match: * See if we match exactly as a host destination
rj_match: ** try to match a leaf, t=3D0pc3a7d980
ipsec_xmit_SAlookup: checking for local udp/500 IKE packet =
saddr=3Da010164, er=3D0pc3a7d980, daddr=3Da01020a, er_dst=3Dac1001f7, =
proto=3D1 sport=3D0 dport=3D0
ipsec_sa_getbyid: linked entry in ipsec_sa table for hash=3D185 of =
SA:tun0x1002@172.16.1.247 requested.
ipsec_sa_put: ipsec_sa SA:tun0x1002@172.16.1.247, ref:314 reference =
count decremented.
ipsec_xmit_encap_bundle: found ipsec_sa -- SA:<IPIP> =
tun0x1002@172.16.1.247
ipsec_xmit_encap_bundle: calling room for <IPIP>, =
SA:tun0x1002@172.16.1.247
ipsec_xmit_encap_bundle: Required head,tailroom: 20,0
ipsec_xmit_encap_bundle: calling room for <COMP_DEFLATE>, =
SA:comp0x55c4@172.16.1.247
ipsec_xmit_encap_bundle: Required head,tailroom: 0,0
ipsec_xmit_encap_bundle: calling room for <ESP_3DES_HMAC_MD5>, =
SA:esp0xe60d3fc@172.16.1.247
ipsec_xmit_encap_bundle: Required head,tailroom: 16,16
ipsec_xmit_encap_bundle: existing head,tailroom: 18,20 before applying =
xforms with head,tailroom: 36,16 .
ipsec_xmit_encap_bundle: mtu:1443 physmtu:1500 tothr:36 tottr:16 =
mtudiff:-5 ippkttotlen:10028
ipsec_xmit_encap_bundle: allocating 14 bytes for hardheader.
ipsec_xmit_encap_bundle: head,tailroom: 32,20 after hard_header =
stripped.
   IP: ihl:20 ver:4 tos:0 tlen:10028 id:165 frag_off:0 ttl:127 proto:1 =
(ICMP) chk:64700 saddr:10.1.1.100 daddr:10.1.2.10 type:code=3D8:0
ipsec_xmit_encap_bundle: head,tailroom: 68,16 after allocation
ipsec_xmit_encap_once: calling output for <IPIP>, =
SA:tun0x1002@172.16.1.247
ipsec_xmit_encap_once: pushing 20 bytes, putting 0, proto 4.
ipsec_xmit_encap_once: head,tailroom: 48,16 before xform.
ipsec_xmit_encap_once: after <IPIP>, SA:tun0x1002@172.16.1.247:
   IP: ihl:20 ver:4 tos:0 tlen:10048 id:257 frag_off:0 ttl:64 proto:4 =
chk:63167 saddr:172.16.1.226 daddr:172.16.1.247
ipsec_xmit_encap_once: calling output for <COMP_DEFLATE>, =
SA:comp0x55c4@172.16.1.247
ipsec_xmit_encap_once: pushing 0 bytes, putting 0, proto 108.
ipsec_xmit_encap_once: head,tailroom: 48,16 before xform.
skb_compress: .
skb_compress: spi=3D000055c4, spi&0xffff=3D55c4, cpi=3D55c4, payload =
size: raw=3D10028, comp=3D100.
ipsec_xmit_encap_once: packet shrunk from 10048 to 124 bytes after =
compression, cpi=3D55c4 (should be from spi=3D000055c4, =
spi&0xffff=3D55c4.
ipsec_xmit_encap_once: after <COMP_DEFLATE>, SA:comp0x55c4@172.16.1.247:
   IP: ihl:20 ver:4 tos:0 tlen:124 id:257 frag_off:0 ttl:64 proto:108 =
chk:7452 saddr:172.16.1.226 daddr:172.16.1.247
ipsec_xmit_encap_once: calling output for <ESP_3DES_HMAC_MD5>, =
SA:esp0xe60d3fc@172.16.1.247
ipsec_xmit_encap_once: pushing 16 bytes, putting 20, proto 50.
ipsec_xmit_encap_once: head,tailroom: 32,9920 before xform.
ipsec_xmit_encap_once: after <ESP_3DES_HMAC_MD5>, =
SA:esp0xe60d3fc@172.16.1.247:
   IP: ihl:20 ver:4 tos:0 tlen:160 id:257 frag_off:0 ttl:64 proto:50 =
chk:7474 saddr:172.16.1.226 daddr:172.16.1.247
ipsec_findroute: 172.16.1.226->172.16.1.247
rj_match: * See if we match exactly as a host destination
rj_match: ** try to match a leaf, t=3D0pc3a7d980
rj_match: *** start searching up the tree, t=3D0pc3a7d980
rj_match: **** t=3D0pc3a7d998
rj_match: **** t=3D0pc10e6b60
rj_match: ***** cp2=3D0pc10ed438 cp3=3D0pc10edc10
rj_match: ***** not found.
ipsec_xmit_restore_hard_header: After recursive xforms -- head,tailroom: =
32,9920
ipsec_xmit_restore_hard_header: With hard_header, final head,tailroom: =
18,9920
ipsec_xmit_send: ...done, calling ip_send() on device:eth0
   IP: ihl:20 ver:4 tos:0 tlen:160 id:257 frag_off:0 ttl:64 proto:50 =
chk:7474 saddr:172.16.1.226 daddr:172.16.1.247
ipsec_rcv: <<< Info -- skb->dev=3Deth0 dev=3Deth0=20
ipsec_rcv: assigning packet ownership to virtual device ipsec0 from =
physical device eth0.
   IP: ihl:20 ver:4 tos:0 tlen:176 id:200 frag_off:0 ttl:64 proto:50 =
chk:7515 saddr:172.16.1.247 daddr:172.16.1.226
ipsec_rcv_decap_once: decap (50) from 172.16.1.247 -> 172.16.1.226
ipsec_sa_getbyid: linked entry in ipsec_sa table for hash=3D167 of =
SA:esp0x89b26986@172.16.1.226 requested.
ipsec_rcv: SA:esp0x89b26986@172.16.1.226, src=3D172.16.1.247 of pkt =
agrees with expected SA source address policy.
ipsec_rcv: SA:esp0x89b26986@172.16.1.226 First SA in group.
ipsec_rcv: packet from 172.16.1.247 received with seq=3D2 =
(iv)=3D0x87f178579ddef444 iplen=3D176 esplen=3D144 =
sa=3Desp0x89b26986@172.16.1.226
ipsec_rcv: encalg =3D 3, authalg =3D 2.
ipsec_rcv: authentication successful.
ipsec_rcv: padlen=3D3, contents: 0x<offset>: 0x<value> 0x<value> ...
           00: 01 02 03
ipsec_rcv: packet decrypted from 172.16.1.247: next_header =3D 4, =
padding =3D 3
ipsec_rcv: trimming to 143.
ipsec_rcv: after <ESP_3DES_HMAC_MD5>, SA:esp0x89b26986@172.16.1.226:
   IP: ihl:20 ver:4 tos:0 tlen:143 id:200 frag_off:0 ttl:64 proto:4 =
chk:7594 saddr:172.16.1.247 daddr:172.16.1.226
ipsec_rcv: SA:esp0x89b26986@172.16.1.226, Another IPSEC header to =
process.
ipsec_rcv: ESP SA sets skb->nfmark=3D0x1340000.
ipsec_rcv: IPIP tunnel stripped.
   IP: ihl:20 ver:4 tos:0 tlen:123 id:199 frag_off:0 ttl:64 proto:108 =
chk:7511 saddr:172.16.1.247 daddr:172.16.1.226
ipsec_rcv: SA:esp0x89b26986@172.16.1.226, inner tunnel policy =
[10.1.2.0/24 -> 10.1.1.0/24] does not agree with pkt contents =
[172.16.1.247 -> 172.16.1.226].

Michael Richardson wrote:

>     Marco> 11:48:48.867133 172.16.1.226 > 172.16.1.247:
>    ESP(spi=3D0x00000100,seq=3D0xf1):
> 172.16.1.226 > 172.16.1.247:
> 10.1.1.10 > 10.1.2.10:
> icmp: echo request (DF) (ipip-proto-4) (ipip-proto-4)
>=20
>   So, there are two IP-IP headers there.
>   There is no reason for this- it is wrong according to RFC2401. I =
also don't
> see an ipcomp there at all, since I guess the packet is too small. =
But, the
> second 172.16.1.226-> header DOES NOT BELONG.
>=20
>     Marco> This is the capture when the packet are compressed (ping -s =
1000):
>=20
>     Marco> 11:49:19.601657 172.16.1.226 > 172.16.1.247:
>    ESP(spi=3D0x00000100,seq=3D0x103):
> 172.16.1.226 > 172.16.1.247:
>      IPComp(cpi=3D0x0100) (DF) (ipip-proto-4)
>=20
>   Again, the second IP-IP header does not belong. It is WRONG, and it =
leads
> to MAJOR insecurity in the VPN.