"Invalid I1 packet with payload detected" when using RVS and HIPFW

Hi,

the HIP standard specifies that the I1 packet should be minimal (i.e., no additional parameters). The hipfw checks for this minimality in order to prevent an I1-based side channel for unauthorized payload data.
From your description, it seems that the RVS functionality adds additional parameters to the I1 packet, which is in conflict with the requirement of minimality.

Miika, can you shed some light on this issue?

Oh and by the way, this should have nothing to do with using certificates.

Thank you for your help. I agree with you, since certificate is only used in R2 packet. But why adding rvs server results in such error? Are there any special configurations needed when using both hipfw and rvs?

The current way of handling the issue conflicts with RVS and also HIPv2 when it hits the trunk. I would suggest to revert this patch from the trunk until its properly solved:

revno: 6363
committer: Diego Biurrun <email address hidden>
branch nick: trunk
timestamp: Tue 2012-03-27 14:51:53 +0200
message:
  hipfw: Reject I1 packets larger than the HIP header size.

  By accepting I1 packets that exceed the HIP header size we would open ourselves
  up to cross-firewall communication. Hosts could exchange I1 packets between
  themselves and attach arbitrary payload after the HIP header.
modified:
  hipfw/conntrack.c
  hipfw/hipfw_defines.h

The mentioned patch also conflicts with RFC 5770 relay extensions. Btw, the RVS part is especially tricky to fix by checking extra parameters because it has to work both when the firewall is between initiator and RVS and also between RVS and responder.

The reasoning for the security issue is also unclear. I assume that the attack scenarios is two malign hosts trying to communicate through a firewall that have somehow learned the HITs of two other hosts that can communicate through the firewall. The question then is that if they learned the HITs through snooping of the traffic, then they can also replay a valid base exchange that bypasses the proposed security measure. Also, it should be noted that in a real scenario one of the hosts has probably infiltrated the (physical) security measures to get access to the LAN.

The patch breaks working code for the sake of not-so-well argument security scenario, so I am going to suggest removing the offending code and opening discussion on a separate bug report or mailing list.

Thanks Miika Komu, that solved my question.