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

Asked by changyou xing on 2012-04-27

Hi all, we are using the hipl-1.0.7, and we configure the hipfw to use its certificate authentication function. When two hosts communicate directly with each other, all things go well. But when we use the rvs server, the hipfw on rvs server outputs "Invalid I1 packet with payload detected, rejecting!", and if we shutdown the rvs server's hipfw, the same error will be generated by the responsder's hipfw. Could anybody help us to solve this problem, and why such thing happens only when using rvs server? Thank you very much.

Question information

English Edit question
HIPL Edit question
No assignee Edit question
Solved by:
Miika Komu
Last query:
Last reply:
René Hummen (rene-hummen) said : #1


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?

René Hummen (rene-hummen) said : #2

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

changyou xing (chyouxing) said : #3

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?

Miika Komu (miika-iki) said : #4

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
  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.

Miika Komu (miika-iki) said : #5

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.

Best Miika Komu (miika-iki) said : #6

The offending patch is removed for further iteration. I haven't had time to precompile binaries yet but does it solve the problem for you?

changyou xing (chyouxing) said : #7

Thanks Miika Komu, that solved my question.