Subject: [Hipsec] HIP checksum dtaft

From: Spencer Dawkins <[email-masked]>
Date: Mon, 19 Nov 2007 16:07:20 -0600

I asked Gonzalo for an opportunity to present a short draft in Vancouver 
(http://tools.ietf.org/wg/hip/draft-dawkins-hip-checksum-coverage-00.txt), 
and we're on the agenda for 10 minutes.

Since that's a short interval, I'd like to ask people to provide impressions 
before the meeting - on-list is fine.

The short summary of the draft is:

- HIP (NAT traversal and RVS) and other working groups (P2PSIP HIPHOP) are 
working on applications that expect to relay HIP packets,

- the current HIP checksums will terminate coverage at a HIP 
relay/NAT/HIPHOP peer. this requires the intermediate HIP(-aware) node to 
recalculate the pseudoheader checksum, and provides no end-to-end checksum 
coverage, so transmission errors introduced at the intermediate node can't 
be detected by checksum failures,

- if the HIP checksums were based on the HIP header and payload, excluding 
any traditional transport pesudo-header fields (especially IP addresses), 
checksum coverage would be end-to-end, and

- (somewhat orthogonal to this) HIPHOP is planning to use HIP in realtime 
signaling applications, and SIGTRAN (in the same space) moved from the 
traditional "ones-complement-sum of the one's complement" 16-bit checksum to 
a CRC32c checksum - so perhaps this checksum calculation would be 
appropriate for HIP as well.

That's the high-level overview. The details are in the draft. The authors 
care what you think. Please let us know.

Thanks,

Spencer 

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 23 Nov 2007 11:09:17 -0800

Spencer,

I had a question about your recently published draft: 

(http://tools.ietf.org/wg/hip/draft-dawkins-hip-checksum-coverage-00.txt
)

It seems to me that your proposal would make the HIP checksum fully
redundant with signature and HMAC, which also cover HIP header + HIP
parameters.  So would it be better to do away with the checksum
altogether? 

- Tom

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 24 Nov 2007 11:57:02 +0200

Spencer,

I think we need to think very carefully about the purpose of the  
checksum.

In the previous HIP drafts, the checksum was very carefully designed  
and placed so that it should be a trivial modification to make  
existing NAT-accelerators to update also HIP checksum if they can  
update the UDP checksum.  That is, the checksum was in the same  
location and and computed in the same way as in UDP.  At some point  
the location was chanced -- I don't remember any more why, perhaps  
due to pressure from SHIM6.  But the computational characteristics  
should still be the same -- if they are not, that is a bug that  
should be fixed.

I think it is important here to understand that there are well- 
established incremental algorithms that allow the checksum to be  
updated when the source and destination addresses in the pseudo  
header are updated.  That's what all NAT boxes do for UDP and TCP.   
So, there is nothing new from that point of view.  The same  
algorithms can be applied, and as I mentioned above, also in some  
cases the existing hardware accelerators can be updated.

 From a computational complexity point of view, updating the IP  
addresses in the real IP header take probably from maybe 15 to a few  
tens of instructions on a typical general purpose CPU.  Read address  
to register (1), use it as an index to a hash table (5-10), read the  
hash bucket (3), write back the result (1).  Looking at the trivial  
algorithm in RFC 1631, I get the impression that for fixed length  
update (as in this case), an optimised checksum update will take  
about 30 instructions.  Other than those two, I would expect that a  
typical implementation CPU-based will use a few hundred machine  
instructions to handle a NATed packet.

Hence, removing the pseudo-header from the checksum would reduce the  
computational load on a typical CPU-based NAT maybe 10%, at most.   
But take that figure with a grain of salt -- I didn't read through  
any specific kernel-based NAT code, just used my general knowledge  
about IP-layer programming.  For hardware-based implementations, the  
biggest hurdle is the placement of the checksum.  However, my  
understanding is that most hardware implementations are already  
flexible about the location of the checksum, since they must be able  
to cover both TCP and UDP, which have the checksum fields at  
different locations in the packet.  Hence, I have a reason to believe  
that most hardware accelerations should be trivially upgradable to  
support HIP checksums.

Given that, and given that all HIP packets but I1 either include an  
HMAC, a signature, or both, I don't see any real reason for the kind  
of checksums that you are proposing.

In my opinion, it is either best to be as close to existing  
implementations as possible, or to remove checksums altogether, if  
they are no longer considered important.

--Pekka Nikander

On 20 Nov 2007, at 00:07, Spencer Dawkins wrote:

> I asked Gonzalo for an opportunity to present a short draft in  
> Vancouver (http://tools.ietf.org/wg/hip/draft-dawkins-hip-checksum- 
> coverage-00.txt), and we're on the agenda for 10 minutes.
>
> Since that's a short interval, I'd like to ask people to provide  
> impressions before the meeting - on-list is fine.
>
> - HIP (NAT traversal and RVS) and other working groups (P2PSIP  
> HIPHOP) are working on applications that expect to relay HIP packets,
>
> - the current HIP checksums will terminate coverage at a HIP relay/ 
> NAT/HIPHOP peer. this requires the intermediate HIP(-aware) node to  
> recalculate the pseudoheader checksum, and provides no end-to-end  
> checksum coverage, so transmission errors introduced at the  
> intermediate node can't be detected by checksum failures,
>
> - if the HIP checksums were based on the HIP header and payload,  
> excluding any traditional transport pesudo-header fields  
> (especially IP addresses), checksum coverage would be end-to-end, and
>
> - (somewhat orthogonal to this) HIPHOP is planning to use HIP in  
> realtime signaling applications, and SIGTRAN (in the same space)  
> moved from the traditional "ones-complement-sum of the one's  
> complement" 16-bit checksum to a CRC32c checksum - so perhaps this  
> checksum calculation would be appropriate for HIP as well.
>
> That's the high-level overview. The details are in the draft. The  
> authors care what you think. Please let us know.
>
> Thanks,
>
> Spencer
>
>