From nobody@www.freebsd.org  Thu Jun 13 08:19:01 2002
Return-Path: <nobody@www.freebsd.org>
Received: from nwww.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by hub.freebsd.org (Postfix) with ESMTP id 5230137B41A
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 13 Jun 2002 08:18:58 -0700 (PDT)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by nwww.freebsd.org (8.12.2/8.12.2) with ESMTP id g5DFIwhG058867
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 13 Jun 2002 08:18:58 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.2/8.12.2/Submit) id g5DFIwY6058866;
	Thu, 13 Jun 2002 08:18:58 -0700 (PDT)
Message-Id: <200206131518.g5DFIwY6058866@www.freebsd.org>
Date: Thu, 13 Jun 2002 08:18:58 -0700 (PDT)
From: Atul Sharma <atul.sharma@nokia.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: NonConforming IPsec implementation from FreeBSD(Kame): AH doesnot interoperate
X-Send-Pr-Version: www-1.0

>Number:         39233
>Category:       kern
>Synopsis:       [ipsec]: NonConforming IPsec implementation from FreeBSD(Kame): AH doesnot interoperate
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bz
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jun 13 08:20:01 PDT 2002
>Closed-Date:    Mon Jan 04 15:39:05 UTC 2010
>Last-Modified:  Mon Jan 04 15:39:05 UTC 2010
>Originator:     Atul Sharma
>Release:        4.5-RELEASE FreeBSD racoon 1.18
>Organization:
Nokia Internet Communications, Nokia
>Environment:
FreeBSD rnc2.iprg.nokia.com 4.5-RELEASE FreeBSD 4.5-RELEASE #6    
>Description:
 Recently while interopertaing Nokia IPxxx boxes' IPsec with FreeBSD Kame IPsec we found problems with AH, (while Nokia interoperated with Cisco and Win2k for all modes). 

Looking at the Kame code there are following problems:

	(1) for IPv4 mutable fields TOS, Flags, Fragment offset are 
            not zeroed out before calculating ICV in the routine
            ah4_calcchecksum() in file ah_core.c like RFC 2402 says. 

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

	    Interestingly, AH tunnel for IPv6 still works, despite an 
            attempt to switch it off, because of the way SPD for IPv6
            case is setup.!!
    
>How-To-Repeat:
  Take a FreeBSD RELEASE 4.5 box and a NOkia IPxxx platform running
  IPSO3.6:

-- Here is the setup

                  BSD (rnc2) <----> IPSO (ipdsqa190)

                  -- The systems are connected back to back
                  -- The BSD is running FreeBSD 4.5 with racoon 1.18
                  -- The following combinations work fine between the 
                     systems:

                  Transport Mode:
                  IPv6 with ESP and AH
                  IPv4 with ESP and AH

                  Tunnel Mode:
                  IPv6 with ESP and AH
                  IPv4 in ESP

                  -- Just the IPv4 AH case doesn't work.
                  -- If the ping starts from IPSO box, I see echo 
                  request in tcpdump but no replies i.e. bsd drops the
                  request itself

                  -- If the ping starts from BSD box, I see both echo
                  request and replies in tcpdump but no output in the 
                  ping program. So BSD drops the replies.
                  -- In both the cases, BSD is dropping IPSO's IPv4 AH 
                  packets

                  -- All the other combinations just work fine so I
                  really don't think that I am configuring something
                  wrong.   
>Fix:
      in ah4_calccksum() zero out iphdr.ip_tos and ip_hdr.ip_off
      lines 756-758.

      in ah_input.c lines 467-468, donot disable M_AUTHIPHDR and 
      M_AUTHIPDGM in the m->m_flags.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Wed Jun 16 09:07:12 GMT 2004 
Responsible-Changed-Why:  
I'm sure I saw something in KAME about this somewhere... 
I'll take this 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39233 
State-Changed-From-To: open->analyzed 
State-Changed-By: bms 
State-Changed-When: Sat Sep 23 10:21:49 UTC 2006 
State-Changed-Why:  
These comments appear to refer entirely to the KAME IPSEC stack, and not 
the FAST_IPSEC stack originally written by Sam Leffler. 
Reviewing the suggested fixes to the current code brings up the following. 

ah_core.c: 
ip_tos may be cleared using net.inet.ipsec.ah_cleartos. 
added by itojun in rev 1.4. 
ip_off may be masked to zero using net.inet.ipsec.ah_offsetmask; 
added by shin in rev 1.1. 
So no immediate changes to code should be necessary when changing 
the checksum calculation. 

ah_input.c 
This is a trust issue and it sounds like it's been around for a long time. 
There are no deltas here against KAME HEAD. 

Several points: 
1. Best way to deal with this situation is to add another sysctl and 
document what's needed for IPSEC interoperability with IPSO? 
2. Perhaps a code drop from Nokia? 
3. Do we have any results in the field about FreeBSD's IPSEC conformance 
e.g. can we test it against something like a Spirent box, or get a 
test lab e.g. UNH to do it? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39233 
Responsible-Changed-From-To: bms->gnn 
Responsible-Changed-By: bms 
Responsible-Changed-When: Sat Sep 23 14:29:36 UTC 2006 
Responsible-Changed-Why:  
Pass to gnn. gnn takes the ball. 

Requested by:	gnn 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39233 
State-Changed-From-To: analyzed->feedback 
State-Changed-By: remko 
State-Changed-When: Sun Dec 31 11:17:51 UTC 2006 
State-Changed-Why:  
george: Did you look into this already? 


Responsible-Changed-From-To: gnn->remko 
Responsible-Changed-By: remko 
Responsible-Changed-When: Sun Dec 31 11:17:51 UTC 2006 
Responsible-Changed-Why:  
Grab the PR to make sure the feedback is mine ;) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39233 
Responsible-Changed-From-To: remko->gnn 
Responsible-Changed-By: remko 
Responsible-Changed-When: Fri Mar 16 10:34:09 UTC 2007 
Responsible-Changed-Why:  
Return to George, no replies so far, if we cannot or will not fix this, 
please close the ticket. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39233 
Responsible-Changed-From-To: gnn->rwatson 
Responsible-Changed-By: rwatson 
Responsible-Changed-When: Fri Jan 25 17:48:31 UTC 2008 
Responsible-Changed-Why:  
Grab this PR, as I've pinged someone at Nokia to ask if they've seen this 
problem on more recent FreeBSD versions.  We have now removed KAME IPSEC 
in FreeBSD 7.0, but it would be very good to know if IPSEC (was 
FAST_IPSEC) suffers from the same problems, and if so, resolve them. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39233 
Responsible-Changed-From-To: rwatson->bz 
Responsible-Changed-By: bz 
Responsible-Changed-When: Tue Apr 8 20:33:03 UTC 2008 
Responsible-Changed-Why:  
See if this also applies to fast_ipsec or if we can get any feedback. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39233 
State-Changed-From-To: feedback->closed 
State-Changed-By: bz 
State-Changed-When: Mon Jan 4 15:37:36 UTC 2010 
State-Changed-Why:  
It seems fast_ipsec has code to do most/everything mentioned in the PR. 
I haven't checked with the RFC and each single IP header field though. 

According to someone from Nokia many many moons back this could be closed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39233 
>Unformatted:
Is this still an issue with the FAST_IPSEC based IPSEC?
