<div dir="ltr">Hi Lan<div><br></div><div>The replay attack scenario requires the attacker to have the ability to block the transmission of an earlier command.</div><div><ol><li>An legit client sends command "1. set light to red".</li><li>Attacker in the middle intercepts this command, and prevents it from being delivered to the light.</li><li>The legit client sends command "2. set light to green".</li><li>Attacker forwards this command to the light.</li><li>Attacker sends the command intercepted in step 2 to the light.</li></ol></div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 1:07 PM, Lan Wang (lanwang) <span dir="ltr"><<a href="mailto:lanwang@memphis.edu" target="_blank">lanwang@memphis.edu</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div dir="ltr">
<div>A sliding window based validation procedure could be: a signed Interest is accepted if its timestamp is greater than (latestTimestamp - windowSize), and it hasn't been accepted previously.</div></div></blockquote></span>
If you always check "it hasn't been accepted previously.", how can an attacker replay it (below)?</div><div><blockquote type="cite"><span class=""><div dir="ltr">
<div>The risk is: an attacker can intercept (and block the transmission of) an earlier command, and replay it later.<br>
</div>
</div></span></blockquote></div></div></blockquote></div><br></div></div></div>