>Number:         36782
>Category:       kern
>Synopsis:       inconsistent packet handling in IPSEC_NAT_T
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 14 16:45:00 +0000 2007
>Originator:     Wolfgang Stukenbrock
>Release:        NetBSD 3.1
>Organization:
Dr. Nagler & Company GmbH
	
>Environment:
	
	
System: NetBSD test-s0 3.1 NetBSD 3.1 (test-s0) #0: Tue Apr 3 11:33:43 CEST 2007 root@test-s0:/usr/src/sys/arch/i386/compile/test-s0 i386
Architecture: i386
Machine: i386
>Description:
	if IPSEC_NAT_T is compiled in the kernel UPD packets mayget checked for ESP inUDP encapsulation if the
	corresponding socket is setup in the INP_ESPINUDP or INP_ESPINUDP_NON_IKE mode.
	The whole thing is located in /usr/src/sys/netinet/udp_usrreq.c.
	The routine that does the removal stuff "udp4_espinudp()" is called around line 760. The code there expects,
	that a return value of -1 means hard error, 1 it was an ESP packet and 0 (or default) no ESP, continue UDP processing.

	But udp4_espinudp() will modify the mbuf chain, so that the value off gets invalid and udp4_sendup() will be called
	with nonsence.
	On the other hand, udp4_espinudp() assumes that it is an ecapsulated packet all the time - so normal UDP procession
	doesn't make realy sence, if udp4_espinudp() will fail for any reason. The port is used for NAT_T or not, but never
	for both at the same time.
	So it would be better to stop UDP-processing for that socket for all packets if the INP_ESP... option is set.
	Therefore after calling udp4_espinudp() there should no call to udp4_sendup() in any case anymore.
>How-To-Repeat:
	not relevant - source code study
>Fix:
	Handle 0 and default in the same way as return value 1 from udp4_espinudp().
	Perhaps drive some statistics dependend on correct ESPinUDP packets and faults.

>Unformatted: