Subject: [Hipsec] Issue 16: Details of LSI handling

From: [email-masked] (Pekka Nikander)
Date: Fri Sep 26 08:17:03 2003

Background
----------

By default, LSIs are selected by taking the low order 24
bits from a HIT.  Each host selects the LSIs for its peers.

It is possible that a host is communicating with two remote
hosts whose low order 24 HIT bits are identical.  It is also
possible that a host needs to communicate with another host
whose low order 24 HIT bits are identical to those of the host
itself.  In such situations the host must select an LSI
that is different from the default one.

Hosts send the selected LSIs to their peers in I2 and R2.
When default LSIs are used, they will be always accepted, since
each host reserves its default LSI to represent itself.

If a Recipient receives an LSI different from the default in I2,
it can check that the LSI is available (not used to represent
some other host).  If the LSI is not available, currently the
host will simply drop the I2.  Since there are quite a few
reasons why an I2 may be dropped, this may not be the best
practise.  On the other hand, it looks like that we need to
regenerate a non-default LSI each time we resend an I2 just
to be sure.

If an Initiator receives an unsuitable LSI in an R2, we have
a bigger problem.  The recipient has already created its state,
and there is no way the Initiator can tell the Recipient that
the LSI is unsuitable.  Basically, it needs to start the
negotiation again (or at least send an I2 with a larger birthday
value), and *hope* that the Recipient will pick a different LSI
this time.

The probability of a collision is not very high.  It basically
requires that there is a collision in both ends, i.e., that the
party selecting the LSI needs to select a non-default LSI, and
the other party cannot accept the non-default LSI.  On the other
hand, if HIP any receives any larger deployment, there will be
collisions (see the probability analysis in the draft).

What to do?
-----------

I am pretty unsure what to do.  Initially there is unlikely
to be problems.  If the hosts select the non-default LSIs
randomly, we will just see a few HIP connections to fail
every now and then.

There is certainly a place for improvement, but I haven't been
able to find one that would be simple and elegant.  Given
that collisions will be fairly rare, I would like the mechanism
to be extremely simple, even if possibly somewhat inefficient.
On the other hand, requiring a full new protocol run seems
like an overkill.

One option is just to document the situation and leave it
open for further experimentation.

Any opinions?  Any nice schemes that would allow us to
solve this problem?

--Pekka Nikander

---

From: [email-masked] (Julien Laganier)
Date: Tue Sep 30 02:45:01 2003

--Boundary_(ID_uqiUHewbVvva+IfHiYGdlQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Folks,

[ Sorry for the late reply but I forget hipsec on CC. ]

--Boundary_(ID_uqiUHewbVvva+IfHiYGdlQ)
Content-type: message/rfc822; name="forwarded message"
Content-description: Julien Laganier <[email-masked]>: Re: [Hipsec]
 Issue 16: Details of LSI handling

Date: Fri, 26 Sep 2003 16:17:22 +0200
From: Julien Laganier <[email-masked]>
Subject: Re: [Hipsec] Issue 16: Details of LSI handling
In-reply-to: <[email-masked]>
To: Pekka Nikander <[email-masked]>
Message-id: <[email-masked]>
Organization: SUN Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: KMail/1.5.3
X-KMail-Transport: SUNW
X-KMail-Link-Message: 217430
X-KMail-Link-Type: reply
X-KMail-EncryptionState: 
X-KMail-SignatureState: 
References: <[email-masked]>
X-Status: S
Status: RO

Pekka,

Some thoughts below,

On Friday 26 September 2003 09:05, Pekka Nikander wrote:

</snip>

> What to do?

A solution I see is to put some signalling stuff in the HIP control bits:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | |P|C| | | | |L| | | | | | |E|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L: LSI unavailable, already used to represent another host. 

In case of collision:
o the responder would send back I2 to the initiator with L bit set
o the initiator would send back R2 to the responder with L set. 

While sending back these packets, the sender should replace by their own the 
SIGNATURE and HOST_ID parameters in I2 and R2.

Receiving these packets, the implementation can then select another LSI to 
represent itself and send back the I2 or R2 packets for another try (and have 
a maximum number of them).

This seems to avoid to run the full exchange again, it's only a round-trip 
long, and it does not require heavy modifications in the protocol, while 
being compatible with legacy implementations (they would drop the sent-back 
I2 or R2).

Any opinions on that? 

Thanks,

--julien

--Boundary_(ID_uqiUHewbVvva+IfHiYGdlQ)--