RE: NonConforming IPsec implementation from FreeBSD(Kame) IPsec?

[Atul.Sharma@nokia.com]

With very best regards, the comments are inline ("Atul>").

Atul

-----Original Message-----
From: ext itojun@iijlab.net [mailto:itojun@iijlab.net]
Sent: Thursday, June 13, 2002 12:05 PM
To: Sharma Atul (NIC/Boston)
Cc: ipsec@lists.tislabs.com; IPD-IPSEC DG; ipsec-project@iprg.nokia.com
Subject: Re: NonConforming IPsec implementation from FreeBSD(Kame)
IPsec? 


>	(1) for IPv4 mutable fields TOS, Flags, Fragment offset are not zeroed out before
>	     calculating ICV like RFC 2402 says. 

	they are properly cleared on ICV computation (otherwise we won't
	interoperate with others).  see sys/netinet6/ah_core.c:ah4_calccksum().

Atul> I looked at the same routine, the code looks like(lines 1232-1236 on
Atul> FreeBSD 4.5 RELEASE):
Atul>
Atul>                iphdr.ip_ttl = 0;
Atul>                iphdr.ip_sum = htons(0);
Atul>                if (ip4_ah_cleartos)
Atul>                        iphdr.ip_tos = 0;
Atul>                iphdr.ip_off = htons(ntohs(iphdr.ip_off) & ip4_ah_offsetmask);
Atul> 
Atul> So ip_tos and ip_off are not unconditionally zeroed like RFC 2402 says.
Atul> The interoperability problem shall come when we have fragments and/or 
Atul> non-zero tos field. For all other traffic one shall not see the difference.

>	(2) AH tunnel mode is not supported. 
>
>	    Even though the code is there, AH tunnel mode is switched off stating that we 
>	    cannot consider the inner IP packet as really authenticated, as it could have been 
>	    tampered with between the host and the tunnel endpoint. It is just the outer IP packet 
>	    which can be considered authenticated. 
>	
>	    Should we make an implementation un-interoperable because of this concern?

	this is a documented caveat.  "not supported" (your wording) is
	a incorrect assertion.
	KAME box can generate AH tunnel mode packet, and accept AH tunnel mode
	packet.  our policy engine do not consider packets inside AH tunnel
	mode packet as "trusted", therefore, we do not permit them to go
	through if ipsec policy is set to "required".  from ipsec(4):

>>     AH and tunnel mode encapsulation may not work as you might expect.  If
>>     you configure inbound ``require'' policy against AH tunnel or any IPsec
>>     encapsulating policy with AH (like ``esp/tunnel/A-B/use
>>     ah/transport/A-B/require''), tunnelled packets will be rejected.  This is
>>     because we enforce policy check on inner packet on reception, and AH au-
>>     thenticates encapsulating (outer) packet, not the encapsulated (inner)
>>     packet (so for the receiving kernel there's no sign of authenticity).
>>     The issue will be solved when we revamp our policy engine to keep all the
>>     packet decapsulation history.

Atul> I must admit that I did not try without "required" in the policy. I shall
Atul> give it a try. Many thanks for pointing that out.

>	    Interestingly, AH tunnel for IPv6 still works, despite an attempt to switch it off, because
>	    of the way SPD for IPv6 case is setup.!!

	i don't believe so.  AH tunnel mode for IPv6 has the same restriction.

Atul> IPv6 seems to have same restriction, but it seems to work. I traced it and the
Atul> reason is that in ip6_input() ipsec6_in_reject() returns 0, because eventually
Atul> in ipsec_in_reject() sp->policy is IPSEC_POLICY_BYPASS or IPSEC_POLICY_NONE 
Atul> and a 0 is returned. In the case of IPv4 in ipsec_in_reject() sp->policy
Atul> hits IPSEC_POLICY_IPSEC, and the last if statement in this routine is hit
Atul> as (need_auth && !(m->m_flags & M_AUTHIPHDR) is TRUE and a 1 is returned...
Atul> and it fails in ip_input().
Atul>
Atul> My IPv6 IPsec policy looks like:
Atul> # IPv6   
Atul> spdadd 1101::1/128 1101::2/128 any -P out ipsec ah/tunnel/1101::1-1101::2/require;
Atul> spdadd 1101::2/128 1101::1/128 any -P out ipsec ah/tunnel/1101::2-1101::1/require;


itojun