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

[itojun@xxxxxxxxxx]

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

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


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

itojun