Re: [Mip4] Remove nonces description for the generic notification message
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mip4] Remove nonces description for the generic notification message



Hello Hui,

Well, in general it is technically better to use nonces.
Nonces don't experience timing skews as clocks do.
Furthermore, in some very small devices, maybe there
wouldn't even be a time-of-day clock.

But those are very general considerations, and you
may have reasons for making the more restrictive
specification.

Regards,
Charlie P.


Hui Deng wrote:
Dear all,

Thanks alexey's remindness.
Orginal document says: ""Timestamps is mandatory and nonces is optional"
we would like to remove nonces description in the document,

Just want to see the mailing list whether there are any objection on it,

thanks

-Hui

2009/9/6 Alexey Melnikov <alexey.melnikov at isode.com>:
4.2.  Generic Notification Acknowledgment Message

 Identification

   if the timestamp of the GNM is valid, the receiver copies the
   entire Identification field into the GNAM it returns the GNAM
   message to the sender. if the timestamp of the GNM is not valid,
   the receiver copies only the low-order 32 bits into the GNAM, and
   supplies the high-order 32 bits from its own time of day.  Both
   GNM and GNAM mandate Timestamps.

What about "nonces"? Note that section 4.1 says:
==> Removed nonces, hope it is ok for u

I don't have strong preference about the fix. You should probably double
check with the WG.

 Identification

   A 64-bit number, constructed by the sender, used for matching GNM
   with GNAM, and for protecting against replay attacks of
   notification messages.  Here is the same as Sections 5.4 and 5.7
   of [RFC3344].  Timestamps is mandatory and nonces is optional.
--
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.