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

From: [email-masked] (Henderson, Thomas R)
Date: Wed Jun 2 22:38:01 2004

> -----Original Message-----
> From: Mika Kousa [mailto:[email-masked]]
> Sent: Tuesday, June 01, 2004 6:46 AM
> To: [email-masked]
> Subject: [Hipsec] Some mm-02-pre1 comments
>=20
>=20
> 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=20
> P-bit value
> is to be interpreted as a truth value (one might hastily=20
> think that it is
> a fixed value).=20

Agreed, this needs to be fixed.

> Similarly as in the base draft's section=20
> 6.2.13 NES the
> description of R-bit value: "One if the NES is a reply to=20
> another UPDATE,
> otherwise zero.".

This may be no longer relevant in the next draft.

> 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=20
> sections implicitly
> assume that at least some REA TLV in the received packet=20
> contains always
> P-bit with value of 1. For example, section 6.1 "Initiating=20
> the protocol
> in UPDATE" says that "The Peer host replies to this with a=20
> reply UPDATE
> packet, sent to the new preferred address". The error here is=20
> 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=20
> base exchange
> (but that's not a "new" address) ? Same assumption is found in section
> 6.2.

Agreed, this could be reworded "the preferred address" in case the
preferred address is not new.  And base exchange address could
be first preferred address.

>=20
>=20
> 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 ?
>

This might be candidate for NOTIFY.  Or else each processed REA
(processed in order) could overwrite the preferred address.

>=20
> Third note: section 8.2 "Handling received REAs" bullet point=20
> 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=20
> on what to do
> if there are these erroneous addresses in the REA. For=20
> example, whether to
> drop the packet or not. Maybe in the same bullet point there=20
> 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.
>=20
>=20
> Then there is a typo "addres" in the same bullet point.

these points are noted-- thanks.

Tom
=20