Subject: [Hipsec] Comment on draft-ietf-hip-base-08

From: Philip Matthews <[email-masked]>
Date: Thu, 30 Aug 2007 11:08:42 -0400

Section 5.1.1 of this document seems to be the normative description  
of the checksum field in the HIP packet. However, to me this section  
seems a bit sketchy on how the value of this field is actually  
computed.  Am I missing something, or is there some implied knowledge  
of how the checksum is computed that is not stated?

- Philip

5.1.1.  Checksum

    Since the checksum covers the source and destination addresses in  
the
    IP header, it must be recomputed on HIP-aware NAT devices.

    If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460]
    contains the source and destination IPv6 addresses, HIP packet  
length
    in the pseudo-header length field, a zero field, and the HIP  
protocol
    number (see Section 4) in the Next Header field.  The length  
field is
    in bytes and can be calculated from the HIP header length field:  
(HIP
    Header Length + 1) * 8.

    In case of using IPv4, the IPv4 UDP pseudo header format  
[RFC0768] is
    used.  In the pseudo header, the source and destination addresses  
are
    those used in the IP header, the zero field is obviously zero, the
    protocol is the HIP protocol number (see Section 4), and the length
    is calculated as in the IPv6 case.

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

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 31 Aug 2007 09:42:26 +0300

What seems to be missing is explicit notion that for HIP packets  
carried over IPv6, the RFC 2460 Section 8.1 Upper-Layer checksum  
algorithm will be used, and for HIP packets carried over IPv4, the  
RFC 768 UDP checksum algorithm will be used.

Would adding that clarify the situation enough, or are you missing  
something else?  Both RFC 2460 and RFC 768 are pretty specific how to  
do that, and there exists a number of implementations for both.

--Pekka

On 30 Aug 2007, at 18:08, Philip Matthews wrote:

> Section 5.1.1 of this document seems to be the normative  
> description of the checksum field in the HIP packet. However, to me  
> this section seems a bit sketchy on how the value of this field is  
> actually computed.  Am I missing something, or is there some  
> implied knowledge of how the checksum is computed that is not stated?
>
> - Philip
>
> 5.1.1.  Checksum
>
>    Since the checksum covers the source and destination addresses  
> in the
>    used.  In the pseudo header, the source and destination  
> addresses are

---

From: Philip Matthews <[email-masked]>
Date: Fri, 31 Aug 2007 07:13:29 -0400

Given your comment, I am also guessing that the pseudo-header is  
logically prepended to the HIP header and the checksum is computed  
starting at the first byte of the pseudo-header and going through the  
last byte of the HIP header (including any TLVs). Is there anything  
else included? For IPv4, I am guessing that the actual formula is the  
one described in the UDP specification:
    Checksum is the 16-bit one's complement of the one's complement  
sum of a
    pseudo header of information from the IP header, the UDP header,  
and the
    data,  padded  with zero octets  at the end (if  necessary)  to   
make  a
    multiple of two octets.
For HIP, I am guessing that there is no need to pad with zero octets.  
Does the following paragraph from the UDP specification also apply to  
HIP?
    If the computed  checksum  is zero,  it is transmitted  as all  
ones (the
    equivalent  in one's complement  arithmetic).   An all zero   
transmitted
    checksum  value means that the transmitter  generated  no  
checksum  (for
    debugging or for higher level protocols that don't care).

What about IPv6? RFC 2460 does not actually describe a checksum  
formula. Is the same formula used? And since, in IPv6, HIP is  
logically an extension header what exactly is covered by the checksum?

The base spec also describes the possibility that HIP packets might  
in the future be used to carry upper-level data (i.e., the NextHeader  
field might be something other that NoNextHeader). In this case, does  
the checksum cover that upper-level data, or only the HIP header?  Or  
is this something that is left "for future specification"?

- Philip

On 31-Aug-07, at 02:42 , Pekka Nikander wrote:

> something else?  Both RFC 2460 and RFC 768 are pretty specific how  
> to do that, and there exists a number of implementations for both.
>
> --Pekka
>
>> description of the checksum field in the HIP packet. However, to  
>> me this section seems a bit sketchy on how the value of this field  
>> is actually computed.  Am I missing something, or is there some  
>>    in bytes and can be calculated from the HIP header length  
>> field: (HIP
>>    Header Length + 1) * 8.
>>

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 31 Aug 2007 15:28:53 +0300

Well, my perhaps faulty understanding is that for both IPv4 and IPv6,  
the currently existing UDP checksum implementations include  
everything from the pseudo header to the end of the payload.  If so,  
the logical implication is that if there are further headers beyond  
HIP (such as UDP and/or SIP, for example), they will be included in  
the checksum.

The intention in HIP has been to be compatible with UDP, thereby  
allowing existing hardware accelerators for updating UDP checksums in  
NATs to be trivially reused.  However, I am not aware of any vendor  
having done an analysis if that is really feasible with the current  
design.

The interpretation of this Section has been a problem in the past in  
the interops.  Therefore, and based on your comments, I think it  
would be very good to clarify it.  However, I haven't implemented it  
myself.  The implementers should speak up.  Perhaps someone who has  
done this could write a clarifying paragraph or two.

--Pekka

On 31 Aug 2007, at 14:13, Philip Matthews wrote:

> starting at the first byte of the pseudo-header and going through  
> the last byte of the HIP header (including any TLVs). Is there  
> anything else included? For IPv4, I am guessing that the actual  
> formula is the one described in the UDP specification:
> For HIP, I am guessing that there is no need to pad with zero  
> octets. Does the following paragraph from the UDP specification  
> also apply to HIP?
> in the future be used to carry upper-level data (i.e., the  
> NextHeader field might be something other that NoNextHeader). In  
> this case, does the checksum cover that upper-level data, or only  
> the HIP header?  Or is this something that is left "for future  
> specification"?
>
> - Philip
>
>>> me this section seems a bit sketchy on how the value of this  
>>> field is actually computed.  Am I missing something, or is there  
>>> some implied knowledge of how the checksum is computed that is  
>>> not stated?
>>>
>>> - Philip
>>>
>>> 5.1.1.  Checksum
>>>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 31 Aug 2007 09:46:03 -0400

Great!  And thanks for your replies.

I should have probably said that all this came up from some  
discussions that a few of us where having around the HIP checksum in  
the context of our HIP-HOP proposal. We don't actually need the  
answers to all these questions, but I just thought it would be useful  
to point out that the definition in section 5.1.1 seems a bit  
underspecified.

- Philip

On 31-Aug-07, at 08:28 , Pekka Nikander wrote:

> Well, my perhaps faulty understanding is that for both IPv4 and  
> IPv6, the currently existing UDP checksum implementations include  
> everything from the pseudo header to the end of the payload.  If  
> so, the logical implication is that if there are further headers  
> beyond HIP (such as UDP and/or SIP, for example), they will be  
> included in the checksum.
>
> allowing existing hardware accelerators for updating UDP checksums  
> in NATs to be trivially reused.  However, I am not aware of any  
> vendor having done an analysis if that is really feasible with the  
> current design.
>
> The interpretation of this Section has been a problem in the past  
> in the interops.  Therefore, and based on your comments, I think it  
> would be very good to clarify it.  However, I haven't implemented  
> it myself.  The implementers should speak up.  Perhaps someone who  
> has done this could write a clarifying paragraph or two.
>
> --Pekka
>
>>    pseudo header of information from the IP header, the UDP  
>> header, and the
>>    data,  padded  with zero octets  at the end (if  necessary)   
>> to  make  a
>>    multiple of two octets.
>> The base spec also describes the possibility that HIP packets  
>> might in the future be used to carry upper-level data (i.e., the  
>>> algorithm will be used, and for HIP packets carried over IPv4,  
>>> the RFC 768 UDP checksum algorithm will be used.
>>>
>>> Would adding that clarify the situation enough, or are you  
>>> missing something else?  Both RFC 2460 and RFC 768 are pretty  
>>> specific how to do that, and there exists a number of  
>>> implementations for both.
>>>
>>> --Pekka
>>>
>>>>    Since the checksum covers the source and destination  
>>>> addresses in the
>>>>    contains the source and destination IPv6 addresses, HIP  
>>>> packet length