[Hipsec] Comments on 5201-bis-02

[René Hummen <[e-mail]>]

Hi everyone,

here are my comments/questions regarding RFC 5201-bis-02:

- 4.6 Certificate Distribution
While I understand the informational reason of having the section "4.5.2 Sending Data on HIP Packets", I fail to see the reason why section 4.6 is included in 5201. Specifically, why is there a need to define the parameter type CERT (768) without further length and value definitions?

- 5.2.16 ACK
The representation of the parameter only lists a single peer Update ID, whereas the transmission of multiple IDs is possible.

- 5.2.19 - 5.2.22 ECHO_*
The definition of these parameters misses eventually required Padding.

- 5.3.5 UPDATE
Since working on HIPL I am wondering why HIP only defines a single UPDATE packet. From the perspective of 5201, I can see a conceptually compelling argument behind this approach, as it allows for a general purpose packet for the transmission of maintenance information. However, most extensions using UPDATE that I know of (most noteworthy, ESP rekeying and mobility and multi-homing) require a 3-way message exchange to complete their corresponding task. The packets thereby have a specific order and each of them has specific semantics. Let's take mobility as an example:
	(1) notify the peer of an address change,
	(2) challenge the peer to confirm his new address, and
	(3) satisfy the challenge.
Still, with the current specifications protocol developers are forced to distinguish between these 3 packets by checking the contained parameter combinations. This is, in my opinion, more complex than necessary and error-prone, especially, with respect to the extensibility of the HIP parameters that can be included in UPDATE packets. So, is there a reason that prevents us from specifying different maintenance packet types instead of a single one?


Best regards,

René


--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.rwth-aachen.de/members/hummen