Subject: [Anima-signaling] Almost final GRASP -08 draft

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Oct 2016 17:33:37 +1300

I think I got everything. For now I have resolved MCR's point about a Session ID
clash by saying that if it happens, we simply drop the incoming request message
if its Session ID is already cached locally. For what should be an incredibly rare
event that seems OK to me. I simulated it in my prototype, and it works OK -
listen_negotiate() reports an error, and any well written ASA will simply try
again. The other end just sees a timeout and tries again.
(Of course this assumes that the session cache is protected by a lock, because
of multithreading, but that is essential anyway.)

So, here is .txt, and html diffs. Summarising the change log:

   Protocol change: Added M_INVALID message.
   Protocol change: Increased Session ID space to 32 bits.
   Enhanced rules to avoid Session ID clashes.
   Corrected and completed description of timeouts for Request messages.
   Improved wording about exponential backoff and DoS.
   Clarified that discovery relaying is not done by limited security instances.
   Corrected and expanded explanation of port used for Discovery Response.
   Added paragraph on extensibility.
   Specified default maxium message size.
   Added Appendix for sample messages.
   Added short protocol overview.
   Editorial fixes, including minor re-ordering for readability.

I'm going to set a timer: if no objections by the end of Friday (in some reasonable
time zone) I'll post the the draft.

I will update the xml on github too.

Rgds, and many thanks to Michael for his detailed review and comments.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Oct 2016 17:20:03 -0400

> if its Session ID is already cached locally. For what should be an

Is it always the case that all negotiations are cached forever?

    > time zone) I'll post the the draft.

I will read the document tomorrow morning.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Oct 2016 11:35:59 +1300

> Is it always the case that all negotiations are cached forever?

No, the race condition only applies to *active* sessions. Once there's
an M_END or a timeout, the session becomes inactive. (Implementation detail:
I decided to just mark sessions as inactive in the session cache, and only actually
delete them when I need to garbage collect. So recent but inactive Session ID clashes
can also be detected, if it matters.)

   Brian