| | | | | | | | |
|
|
|
You're here: Home |
Geoff Huston wrote:
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.The one bit that continues to worry me is that you were positing a 24 hour lag to reset the msg-ref value when the client drops its state - which seems tobe an undue imposition.One possible way out is for the server to respond with the last seen msg-ref value to the client iff the client's message is well-formed (i.e. correctly signed and validated)Yes / No?
I think it's reasonable to say that the client has to remember its highest msg_ref value. However, if there's a fear that a reactor meltdown will destroy that information, they are advised to use seconds since epoch or something similar, as RobA suggested.
That would save us from the 24 hour resting period and the last_msg_ref too. (I guess that makes the answer to the above question a 'no'.)
Cheers, Robert
2) While I find the numeric error codes distasteful, that's just syntax. The real issue here is that you (Geoff) still appear to consider the error codes to be something that's outside the protocol, and I don't. Whatever the syntax, the schema really should be able to look at an error PDU and say "this is a valid error" or "this is not a valid error". So they need to be enumerated in the schema, and no unspecified errors are allowed. Yes this means that the schema changes when the error codes change. That's the point.I'll ask Byron to look at this. regards, Geoff _______________________________________________ Rescert mailing list Rescert@apnic.net http://mailman.apnic.net/mailman/listinfo/rescert
