draft-ietf-ipsec-udp-encaps-06 comments.

Jean-Francois Dive <jef@linuxbe.org> Wed, 11 June 2003 13:34 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08288 for <ipsec-archive@lists.ietf.org>; Wed, 11 Jun 2003 09:34:00 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA08026 Wed, 11 Jun 2003 07:31:46 -0400 (EDT)
Date: Wed, 11 Jun 2003 13:36:50 +0200
From: Jean-Francois Dive <jef@linuxbe.org>
To: ipsec@lists.tislabs.com
Cc: jef@linuxbe.org
Subject: draft-ietf-ipsec-udp-encaps-06 comments.
Message-ID: <20030611113650.GD1043@gardafou.assamite.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.3i
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

Hi all,

I am actually busy with implementing NAT-T in IKEv1 context and found something which may have been
overlooked (or that i missed the discussion on this list). In section 3.1.2, the author talk about the
procedure to follow for udp encpasulated transport mode NAT decapsulation. I totally agress with the 
first point (point (a)) but think the second point (point (b)) is totally wrong and should never be 
implemented as such: it is suggested that if we dont have the original source or destination ip 
addresses, the TCP/UDP checksum of the packet should be recomputed to match the NAT'ed ip pseudo header. 
This cant happen as it would make corrupted packets appears as proper packets, the checksum "mangling"
or update beeing right as a wrong checksum at the start would remain wrong. The only proper way to 
deal with this would be to go with checksum update when you have the information and no checksum 
at all if you dont have the information. 

Any comments ?

Thanks,

Regards,

Jean-Francois Dive

-- 

-> Jean-Francois Dive
--> jef@linuxbe.org

  There is no such thing as randomness.  Only order of infinite
  complexity. - Marquis de LaPlace - deterministic Principles -