On 07/07/2010, at 11:25 PM, Rob Austein wrote: > At Wed, 7 Jul 2010 19:33:01 +1000, Geoff Huston wrote: >> >> I also have not seen any alternate approach to replay protection on >> the WG mailing list other than your assertion that "adding it would >> not be hard". > > http://www.ietf.org/mail-archive/web/sidr/current/msg01538.html
The ensuring short exchange was inconclusive as far as I can tell. The four options that were considered at the time raised by yourself and Rob Kisteleki were: a) treat the sender's time in the CMS as a monotonically increasing sequence and insist that every message from a sender uses a higher value than the previous message. my understanding of this is: pros - already in the CMS cons - if the time at a second level granularity is used, then the request rate is limited b) use an explicit sender's message id, and treat this as a strict (+1) counter where a jump in the counter value is also detected my understanding of this is: pros - can also detect requests that have not made it cons - change to the XML spec c) use a) with a nanosecond granularity my understanding of this is: pros - addresses the maximum request erate problem cons - rfc4049 and RFC5652 both specify time in seconds, so its not possible to directly use the CMS signing time fields here d) use a) but allow the sender to have a time equal to or higher than the time of the previous request my understanding of this is: pros - already in the CMS cons - rapid fire replay and reordering is possible. Is reordering of messages (request and revoke) a concern here? My personal opinion is that d) would be adequate as long as the potential for MITM reordering was considered to be relatively harmless. Is this the case? Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
