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

["Henderson, Thomas R" <[e-mail]>]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] 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:
> >     (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?
>
> 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
>

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