Subject: [Hipsec] Comments on 5201-bis-02

From: René Hummen <[email-masked]>
Date: Sun, 04 Jul 2010 00:36:44 +0200

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: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 4 Jul 2010 10:14:56 +0300

> 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 t…

The original idea was that UPDATEs would just be a "carrier" for upper level protocols, allowing upper level protocols to be mixed and matched on individual packets.  E.g. so that you could run a mobility exchange and ESP rekeying at the same time, with the same packets.  E.g.

    A->B:  Notify address change
    B->A:  Challenge address; Initiate ESP rekeying
    A->B:  Send the challenge response; Continue ESP rekeying
           etc.

But since I haven't been involved in implementation efforts for the last N years, I don't know if the current implementations support such behaviour

--Pekka

---

From: Miika Komu <[email-masked]>
Date: Sun, 04 Jul 2010 13:12:25 +0300

On 07/04/2010 10:14 AM, Pekka Nikander wrote:

Hi Pekka and Rene,

> But since I haven't been involved in implementation efforts for the last N years, I don't know if the current implementations support such behaviour

the carrier statement is still valid but UPDATE but I doubt if it's 
utilized much. I think relabeling the UPDATE control headers would be ok 
even with simultaneous rekeying but please correct if I'm wrong. Seems 
like registration as defined in RFC5203 would work still nicely with 
relabeled UPDATEs.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 4 Jul 2010 21:07:57 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Pekka Nikander
> Sent: Sunday, July 04, 2010 12:15 AM
> To: René Hummen
> Cc: HIP WG
> Subject: Re: [Hipsec] Comments on 5201-bis-02
>
> > - 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:
> > 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?
>
> The original idea was that UPDATEs would just be a "carrier"
> for upper level protocols, allowing upper level protocols to
> be mixed and matched on individual packets.  E.g. so that you
> could run a mobility exchange and ESP rekeying at the same
> time, with the same packets.  E.g.
>
> But since I haven't been involved in implementation efforts
> for the last N years, I don't know if the current
> implementations support such behaviour
>

I tend to agree with Rene's observations and think it would be worthwhile to examine his proposal in the new protocol version.  I am curious how often the implementations actually couple the rekeying with address change notifications in practice.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Mon, 05 Jul 2010 09:49:52 +0300

On 07/05/2010 07:07 AM, Henderson, Thomas R wrote:

Hi Tom,

> I tend to agree with Rene's observations and think it would be worthwhile to examine his proposal in the new protocol version.  I am curious how often the implementations actually couple the rekeyi…

this hasn't been the case at least in HIPL.

---

From: Jan Melen <[email-masked]>
Date: Tue, 6 Jul 2010 16:37:47 +0300

> this hasn't been the case at least in HIPL.

And the opposite, that has been the case for HIP4inter.net. :-)

    Jan