Subject: [Capwap] Proposed text for Issue 236: retransmission of DTLS encrypted control packets

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 20 Feb 2007 12:47:42 -0800

All,
 
This issue was raised at the interim. The basic problem is that if one
attempts to retransmit a packet that has already been DTLS encrypted,
the peer would identify the packet as a relay, and would drop it. The
fundamental problem here is how to fix an issue where the response
packet was lost. It is necessary in those cases to make sure that the
peer receives and processes a retransmitted request, and re-sends the
response.

In trying to fix this, it became clear that it was necessary to
introduce a section on retransmissions to begin with, which is what the
following text does.

Comments welcomed.

<text>
4.4.3.  Retransmissions

   The CAPWAP control protocol operates as a reliable transport.  For
   each request message, a response exists, which is used to acknowledge
   receipt of the request.  Further, the control header's sequence
   number is used to pair the request and response messages (see section
   Section 4.4.1).

   Response messages are not explicitly acknowledged, therefore if it
   was not received, the original request would be retransmitted.
   Implementations MAY cache response messages in order to be able to
   respond to a retransmitted request with minimal local processing.
   Therefore, retransmitted requests MUST NOT be altered by the sender,
   as it MUST assume that the original request was processed, but the
   response was lost in the network.  Any alterations to the original
   request MUST have a new sequence number, and is treated as a new
   request by the receiver.

   After transmitting a request message, the RetransmitInterval (see
   section Section 4.6) timer and MaxRetransmit (see section
   Section 4.7) variable are used in order to determine whether the
   original request needs to be retransmitted.  Response messages are
   not subjected to these timers.

   When a request is retransmitted, it MUST be re-encrypted via the DTLS
   stack.  The reason being that if the peer had received the request,
   but the corresponding response had been lost, it is necessary to
   ensure that retransmitted requests are not identified as replays by
   the DTLS stack.  Similarly, any cached responses that are
   retransmitted as a result of receiving a previously received request
   MUST be re-encrypted via DTLS.

   Duplicate response, identified by the Sequence Number field in the
   CAPWAP control message header, SHOULD be discarded upon receipt.
</text>

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap