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

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 2 Jun 2004 20:31:55 -0700

> -----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
> 
> 
> 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). 

Agreed, this needs to be fixed.

> 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.".

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 
> 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.

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.

> 
> 
> 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.

> 
> 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.

these points are noted-- thanks.

Tom
 
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec