Subject: Re: Another NAT Traversal question

From: Francis Dupont <[email-masked]>
Date: Sat, 01 Mar 2003 14:57:57 +0100

In your previous mail you wrote:

   > => my concern is that I believe the way you fix the checksum will give
   > a correct checksum from a wrong one, i.e., you loose the detection
   > of errors which is the purpose of the checksum.
   > IMHO the checksum must be fixed using the original and new IP
   addresses,
   > i.e., you add the original addresses and substract the new addresses
   > in an one-complement arithmetic (the checksum is the opposite of the
   > sum of the pseudo-header and the transport message in one-complement.
   > At the exception of UDP/IPv4, zero is normalized, i.e., +0 is used.
   > What I propose is a direct application of RFC 1624 which requires
   > the original addresses).
   > 
   
   I don't think you need to do what you have explained.

=> I need it if I consider the transport layer is independent.

   Since you will
   authenticate and decrypt the packet, it guarantees that you don't have
   any flipped bits in the body of the encapsulated data.
   
=> the transport checksum is between transport layers. If I believe
in your argument, it is impossible to get errors as soon as packets
don't go through a link without CRCs... This is contrary to real
world experiences where bad TCP checksums occured on an Ethernet link...
 IMHO we should not violate the principle of layer separation here.

   If you want, test the checksum before you authenticate/decrypt the
   packet.
   
=> how? the checksum is ciphered.

Regards

[email-masked]

PS: about NAT traversal for IKEv2, I always follow Tero Kivinen's I-D
(draft-ietf-ipsec-nat-t-ike-05.txt) which is a complete and already
used (i.e., experimentally proved) specification.

---

From: "Jayant Shukla" <[email-masked]>
Date: Sat, 1 Mar 2003 19:46:44 -0800

> -----Original Message-----
> From: [email-masked] [mailto:Francis.Dupont@enst-
> bretagne.fr]
> 

Transport layer is not independent of IP layer. The pseudo-header in
transport layer checksum contains IP header information. 

> => how? the checksum is ciphered.

Checksum of the UDP header! If you check the checksum of the UDP header,
and authenticate the packet, how in the world can you have errors or
wrong checksum in the encapsulated part of the packet (I mean apart from
the wrong IP address)? Please explain!

Regards,
Jayant
www.trlokom.com

---

From: Francis Dupont <[email-masked]>
Date: Sun, 02 Mar 2003 15:20:26 +0100

> => I need it if I consider the transport layer is independent.
   
   Transport layer is not independent of IP layer.

=> it is a wording concern. What I tried to mean is that the
transport layer and the network layer are two different layers.

   The pseudo-header in

   
=> for instance in the hardware which manages IPsec and the main memory.
There is a lot of stuff about this in the archive because the discussion
about "why the transport checksum is mandatory even we use links with
stronger error detection, ..." is very recurrent (just a bit less
than "why IPv6 has no header checksum").

BTW I propose to move the object of this discussion to Tero's NAT
traversal I-D (draft-ietf-ipsec-nat-t-ike-05.txt) which seems to
be already implemented and used.

Regards

PS: I didn't follow the iSCSI list but I'll be surprised if there is
nothing about "remove the transport checksum because ..." in its archive.

---

From: Ari Huttunen <[email-masked]>
Date: Mon, 03 Mar 2003 14:18:29 +0200

Jayant Shukla wrote:
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Francis Dupont
>>
> I don't think you need to do what you have explained. Since you will

No, this guarantees only that the bits didn't flip while they
were encrypted. If the bits were flipped before they entered
the ESP tunnel, that's another question.

Please don't anybody try to reinvent the wheel, unless you
find the existing wheel is not round enough. :)

Ari

-- 
I play it cool and dig all jive,
  that's the reason I stay alive.
   My motto as I live and learn,
    is dig and be dug in return. <Langston Hughes>

Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com

F(ully)-Secure products: Securing the Mobile Enterprise

---

From: "Jayant Shukla" <[email-masked]>
Date: Mon, 3 Mar 2003 09:16:53 -0800

> On Behalf Of Ari Huttunen
> >

So you are worried about the errors before the packet hits the
wire?!!!!!!!
Remember we are talking about the transport mode processing, so that
packet has not hit the wire yet.

What I gather from the RFC 760 is that the checksums were meant to
detect errors on the wire.

Quote from RFC 760
---
"Damage is handled by adding a checksum to each segment transmitted,
checking it at the receiver, and discarding damaged segments."
---

I laud your effort if you want to use the checksum to detect the errors
inside the device. BTW, do you also have a mechanism to detect errors
that may happen when the data is handed over by the application to the
TCP/IP stack? 

> find the existing wheel is not round enough. :)

Not unless someone has turned a wheel into a square peg.

Transport mode is supposed to be end-to-end (client to client), and
transport mode with NAT traversal is _not_ end-to-end secure. This
should be enough reason for the area directors to kill it.

Regards,
Jayant
www.trlokom.com

---

From: Henry Spencer <[email-masked]>
Date: Mon, 3 Mar 2003 12:57:45 -0500 (EST)

> detect errors on the wire.

Note that RFC 760 is obsoleted by RFC 791.

Wire-level CRCs etc. are normally necessary and sufficient for detecting
errors on the wire.  The TCP/IP checksums are primarily for errors that
are not caught by wire-level mechanisms, such as bugs in router firmware. 

> that may happen when the data is handed over by the application to the

It has been observed in the past that the TCP and UDP checksums ideally
should be generated and checked by the application (presumably by a
subroutine library it calls), not by the system, to give the strongest
possible end-to-end checking -- that being what those checksums are for. 
There are practical difficulties with that, but it's a useful model.

                                                          Henry Spencer
                                                       [email-masked]