APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists rescert 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Rescert] Another attempt to round off the IR-ISP protocol



Rob Austein wrote:
So, at this point I think we have two real issues, and some trivial
stuff.  I'm going to ignore the trivial stuff for now.

1) On the replay protection thing: Randy and I have been talking to
   Steve Bellovin, and while we haven't quite converged yet it looks
   like the simplest answer is to follow RobK's earlier suggestion:
   just make the msg_ref a monotonically increasing integer, no CMS
   timestamp required, no reset mechanism required, done, full stop.
   The likely implementation would be to generate the msg_ref value
   from a clock on the sender side, eg, nanoseconds since epoch, but
   it really doesn't matter so long as it's monotonically increasing.
   The CMS timestamp doesn't isn't fine enough for this, and combining
   CMS timestamp with an additional value has timing screws, so let's
   just keep this simple and go with the counter.

   Steve Bellovin doesn't quite believe this yet but I think that
   Randy and I can convince him.  We'll keep you posted.


We've talked about this approach as well, and there are a few nits that continue to be bothersome when thinking about this:

1. How old (in terms of CMS signing time) a message are you as a server prepared to accept? Should be be a limit, or are we happy processing messages that purportedly were signed years ago?


2. What happens as a client when you are using a simple incremented counter for msg_ref and you reboot? How do you resume msg_ref?

3. If the answer to q2 is the clock (as per your note above) what happens as a client if NTP sets your clock backwards in time? Or just freezes the clock?


Geoff