> > > ### HIP Checksum ### > > > > 5.1.1. Checksum > > > > What is the reason for using the IP-based pseudo-headers here? If I > am > > not overlooking something, non-HIP-aware NATs on the communication > > path effectively break the HIP checksum. I know that this is the way > > how TCP/IP pseudo-headers are defined. Still, I suggest to only > > checksum the HIP header and the HIP parameters to avoid problems in > > the future and to maintain layer separation. What happens if HIP is > > used in non-IP environments? > > I have never liked the pseudo-header concept myself either but I think > it's mandated by IPv4 and optional in IPv6 (for instance, with UDP).
For UDP, it is the reverse of the above (optional for IPv4, mandatory for IPv6). > For instance, RFC5770 overrides that HIP checksum should be zero when > the HIP control packet is encapsulated in UDP: > > http://tools.ietf.org/html/rfc5770 Yes, but UDP checksum covers IPv6 header in that case. There is also a proposal to zero the UDP checksum in other UDP tunnel situations: http://tools.ietf.org/html/draft-ietf-6man-udpzero-06 but I haven't seen it proposed for non-tunnel situations. > > 5.1. HIP Control Packets: > > The HIP header and parameters follow the conventions of [RFC5201] with > the exception that the HIP header checksum MUST be zero. > > Authors, can we get rid of the pseudo header or are we stuck with it? > Or can we make it optional (like with UDP and IPv6)? > > I think we can live with it but, at least, it would be useful to > mention that the checksum MAY be zero depending on the underlying > encapsulation as specified by further extensions. I am hesitant to be a trailblazer in removing the IPv6 header integrity checking. I'd rather add a note such as you suggest (if underlying transport provides necessary integrity check, as specified in other documents). - Tom _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
