Subject: [Hipsec] Some mm-02-pre1 comments

From: Mika Kousa <[email-masked]>
Date: Tue, 1 Jun 2004 16:46:06 +0300 (EEST)

In section 7.1 "REA parameter" of draft mm-02-pre1, the description of
P-bit value in the REA TLV does not clearly indicate that the P-bit value
is to be interpreted as a truth value (one might hastily think that it is
a fixed value). Similarly as in the base draft's section 6.2.13 NES the
description of R-bit value: "One if the NES is a reply to another UPDATE,
otherwise zero.".

So, the description of P-bit could be changed to: "Preferred address. One
if the first address in this REA is the new preferred address, otherwise
zero."

Assuming that I understood right that the P-bit is a truth value, I
noticed some issues in the mm-02-pre1. Looks like some sections implicitly
assume that at least some REA TLV in the received packet contains always
P-bit with value of 1. For example, section 6.1 "Initiating the protocol
in UPDATE" says that "The Peer host replies to this with a reply UPDATE
packet, sent to the new preferred address". The error here is that which
address should we choose if the P-bit is not set in the REA in the
received initial UPDATE packet ? The one we got during the base exchange
(but that's not a "new" address) ? Same assumption is found in section
6.2.

Another note: what should we do if there are multiple REA TLVs in the
packet and there are more than one set P-bit ? Drop the packet as
erroneous ?

Third note: section 8.2 "Handling received REAs" bullet point 2 says: "For
each address listed in the REA parameter, check that the address is a
legal unicast or anycast address. That is, the addres MUST NOT be a
broadcast or multicast address." There are no more comments on what to do
if there are these erroneous addresses in the REA. For example, whether to
drop the packet or not. Maybe in the same bullet point there should also
read "If the REA parameter contains broadcast or multicast addresses,
these addresses MUST be ignored". Packet processing can be continued
anyway, because this does not seem to be a fatal situation.

Then there is a typo "addres" in the same bullet point.
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Mika Kousa <[email-masked]>
Date: Tue, 15 Jun 2004 18:17:59 +0300 (EEST)

More comments:

How can we inform the peer on multiple usable inbound SPIs ?

After the base exchange we have one SA with inbound SPI (let's say SPI_1),
associated with some IPv6 address A_1, similarly as in Figure 1 in chapter
5.1 of mm-02. Then we would like to add another network interface, so we
send an UPDATE packet which contains the addresses belonging to this
interface. When building this packet we create a new inbound SA with
SPI_2, add a REA parameter to the packet with SPI field set to SPI_2.

After adding REA we have to add the NES parameter. The New SPI field in
this NES is simple, it is set to SPI_2 (right ?). But what should we put
into the Old SPI field ? If we set it to SPI_1, then the SA corresponding
to SPI_1 is deleted when the reply UPDATE is received, therefore resulting
in a situation where we have only one inbound SA and not two separate
inbound SAs as should have been the case. Also, we can't just set Old SPI
to some fixed value, because 0-255 are reserved SPI values and the
remaining values can not be used because the SPI should be random anyway.
Third note is that I guess the Old SPI must match to some SPI which has
been in use before (if not, the received UPDATE packet is erroneous and
must be dropped).

Do we need a new parameter (or modify NES) for indicating that the old SAs
should not be deleted ? I read and re-read the draft several times but I
couldn't figure out how the simultaneous SPI/address associations can be
accomplished as in Figure 2 of chapter 5.1. Or have have just
misunderstood something..
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Mika Kousa <[email-masked]>
Date: Thu, 17 Jun 2004 15:04:06 +0300 (EEST)

There is a conflict in parameter type values: draft-ietf-hip-base-00
specifies SPI parameter as Type 1 and mm-02-pre1 draft specifies also that
REA parameter has Type 1. This should be fixed when final version of mm-02
is released.
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec