HIPL

pure hip vs. udp encapsulation

Asked by René Hummen

Hello everyone,

I noticed that (at least in our scenario in Aachen), we always use UDP encapsulation for HIP transmissions. Furthermore, plain-NAT is the default mode of operation for HIPL. I don't see this situation changing any time soon (i.e. middleboxes such as NATs becoming HIP-aware).

Now, HIPL uses raw sockets for everything. That even includes sending UDP packets! Raw sockets cause extensive overhead in terms of code size and code complexity, as whole IP packets have to be created and routes need to be queried.

My suggestion is to get rid of most of this complexity by focusing on the UDP mode of operation. Doing so would allow to remove raw socket-specific functionality and to let the OS do the IP-based work.

This is an invitation for the discussion of my proposal.

Question information

Language:
English Edit question
Status:
Answered
For:
HIPL Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Stefan Götz (stefan.goetz-deactivatedaccount) said : 		#1

I guess I'm the least qualified person to comment on this, but I would say reducing code complexity is a very very good thing. On the other hand, I'd be a bit reluctant to reduce HIPL to the point where it is intentionally no longer RFC compliant.

Revision history for this message
Miika Komu (miika-iki) said : 		#2

You forgot to add that raw sockets also reduce portability. There's a silly, albeit popular operating system, that doesn't allow them. Also hipd requires root privileges due to IPsec and routing interaction, but raw sockets add yet another nail to the coffin.

However, I agree with Stefan that we should still have raw sockets for RFC compliance. And there's some unquestionable benefits from raw sockets. Hipfw uses them to reinject modified packets. Hipd uses them to achieve agility for network I/O as follows.

Hipd creates two raw sockets per address family: one for input and one for output. If hipd created just one socket, it would have to bind it to certain address for packet transmission and, then, the input from other addresses would be inadvertently filtered out. We've actually experienced this.

The UDP communications is based on raw sockets as well for three reasons. First, it is not possible to create two UDP sockets (for input and output) that reuse the same port. Second, setting the source or destination ports would act as benign filter even if we were to use a single UDP socket. Lastly, the UDP code has a very minimal footprint because as it is a small extension of the raw socket code (which just adds the UDP header to the packet).

The raw sockets are also convenient for broadcasting and implementing extensions like "shotgun". So, the current raw socket design is the refined result of an long-term, experimental evolution and therefore I wouldn't throw it away too hastily.

Can you help with this problem?

Provide an answer of your own, or ask René Hummen for more information if necessary.

To post a message you must log in.