Subject: [Pana] Alternative sequence numbering scheme

From: Alper Yegin <[email-masked]>
Date: Fri, 27 Aug 2004 10:51:29 -0700

Here is Susan Thomson's e-mail on the proposed scheme.
I think this is aligned with what Yoshi was describing as well.
 
Alper
 
-----Original Message-----
From: Susan Thomson [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2004 6:55 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: follow-up to PANA sequencing discussion
 
Hi Alper

A belated follow-up to sequencing discussion from IETF.

If the point of the second sequence number  is blind DOS protection
only, then an alternate proposal may be to rely on the session ID for
protection by making it a random number.

This frees up the sequencing scheme to use a single sequence number.

Assuming a request-response model where it is clear which messages are
requests and which responses, the sequence numbering works as follows:

[Note that a single component may play role of initiator or responder
for different message types depending on the protocol. In this case,
each endpoint of the protocol maintains two "current" Message IDs: the
next one to be used for a request it initiates and the next one it
expects to see in a request from the other end.]

The Initiator sets the Message ID in the header to any  value (e.g. 0)
in the first message of the session, and increases the Message ID by one
for each new request using serial number arithmetic. Retransmissions do
not increment the Message ID. Responses contain the same message ID as
the request. 

After the initial handshake, the Initiator keeps track of the current
Message ID to increment for new requests, to match up requests and
responses, and to identify retransmissions of messages. Likewise, the
Responder keeps track of the current Message ID to identify when a
request is new or when it is a retransmission. The Initiator is always
responsible for retransmissions. The Responder only retransmits a
response on seeing a retransmitted request; it does not otherwise
process the retransmitted request. 

If window is one (which I think it is for this protocol), the Initiator
must not send a new request until it receives a response to the previous
one. The Responder must remember a response until a request with a new
Message ID is received.

The above  is arguably simpler and can make use of a scheme that is
close to what many UDP-based protocols and thus is "tried-and-tested".
For example, the above is the same scheme that IKEv2 specifies.

Thanks
Susan

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana