[SECNET PATCH 11/12] polypath asymmetric routing: Handle MSG1 late dupes

[Ian Jackson]

If we get a MSG1 and it seems too late for the protocol stage, and it
had the same peer nonce, it was probably an old packet via a different
route.

In theory it might seem like we should do this in SENTMSG3 and 5 too
because we might have had concurrent setup, and higher priority, so the
peer also sent us MSG2 or 4.  But mobile peers have priority.

Signed-off-by: Ian Jackson <ijackson at chiark.greenend.org.uk>
---
 site.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/site.c b/site.c
index 148e7db..70e4b02 100644
--- a/site.c
+++ b/site.c
@@ -1824,9 +1824,21 @@ static bool_t site_incoming(void *sst, struct buffer_if *buf,
 		BUF_FREE(buf);
 		return True;
 	    }
+	} else if (st->state==SITE_SENTMSG2 ||
+		   st->state==SITE_SENTMSG4) {
+	    if (consttime_memeq(named_msg.nR,st->remoteN,NONCELEN)) {
+		/* We are ahead in the protocol, but that msg1 had the
+		 * peer's nonce so presumably it is from this key
+		 * exchange run, via a slower route */
+		transport_setup_msgok(st,source);
+	    } else {
+		slog(st,LOG_UNEXPECTED,"competing incoming message 1");
+	    }
+	    BUF_FREE(buf);
+	    return True;
 	}
 	/* The message 1 was received at an unexpected stage of the
-	   key setup. XXX POLICY - what do we do? */
+	   key setup.  Well, they lost the race. */
 	slog(st,LOG_UNEXPECTED,"unexpected incoming message 1");
 	BUF_FREE(buf);
 	return True;
-- 
2.11.0