[4553] in Kerberos
Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
daemon@ATHENA.MIT.EDU (Dan Nessett)
Thu Feb 2 12:23:36 1995
Date: Thu, 2 Feb 1995 09:04:56 -0800
From: Danny.Nessett@Eng.Sun.COM (Dan Nessett)
To: Jim_Miller@suite.com
Cc: kerberos@MIT.EDU, cat-ietf@MIT.EDU
> From jim@bilbo.suite.com Wed Feb 1 15:21:59 1995
> To: Danny.Nessett@Eng
> Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
> Cc: kerberos@ATHENA.MIT.EDU, cat-ietf@MIT.EDU
[text deleted]
>
> I can see how your window mechanism would work.
>
> Just for grins, here's an expanded description on the idea in my previous
> post.
>
> Each ticket would describe a range of sequence numbers using an initial
> random number and a message count. In this way a ticket would be "good
> for" a certain number of messages, in addition to being valid a certain
> length of time.
>
> Client Side:
>
> Each time a client sends a message, it would get the "next number" from
> the ticket (credential, actually) and use it as the message sequence
> number. If the "next number" > (initial number + message count), then the
> client would have to get a new ticket.
>
>
> Server Side:
>
> Server receives the message, decodes/decrypts it and examines the endtime
> of the appropriate ticket. If the ticket has expired, then the message is
> rejected (i.e. Messages secured using these kinds of sequence numbers
> would expire when the ticket used to secure them expires.). Assuming the
> ticket has not expired, and the other checks pass, the server examines the
> sequence number. The sequence number must fall within the range of
> numbers described in the ticket used to secure the message (duh).
>
> To cut down on the amount of replay information that would have to be
> searched, the server maintains a number (N) indicating the lowest number
> in the range below which all numbers have already been received.
>
> Hmm, that doesn't sound very clear. Assume that all sequence numbers from
> "initial number " through N have arrived. Now, if a message comes in with
> a sequence number < N you don't have to search through the replay cache to
> know its a replay.
>
> So, instead of simply searching the replay cache, you first compare the
> message's sequence number with N. If the sequence number <= N you know
> its a replay. If the sequence number is > N, you search the replay cache.
> If a replay record exists that contains a matching client, server, and
> sequence number, then the message is a replay. The replay cache search
> will also tell you when it is time to increment N.
>
> My N is kind of like your sliding window, but it only tracks the lower-end
> of the window.
>
> Finally, the replay cache expunge code could be modified to remove records
> with sequence numbers < N. Of course, this implies the various Ns
> associated with the tickets are somehow stored in the replay file. I have
> an idea on how to do this, but I don't feel like going into details in
> this post.
>
Jim,
I think both schemes are similar. Let me try to analyze them from a strengths
and weaknesses point of view :
Fixed Sequence Number Range Scheme
----------------------------------
Strength : Packets will never be discarded erroneously because they arrive
very late. This is a weakness of the Sliding Window scheme, although the
probability of this happening can be made small by an appropriate choice
of window size.
Weakness : The application will have to guess the rate at which packets will
be generated during the ticket validity period. However, using sufficiently
large validity periods should mitigate the performace hit of resynchronizing by
resending a ticket.
For sufficiently large sequence number spans, the amount of space
allocated by the server to handle the book keeping associated with keeping track
of which packets have arrived and which haven't could be large. Since the
span length is under the client's control, the server would loose control
of its resources. Of course, the server could impose a maximum limit to
the span size, but then for certain client packet rates, this might
induce an unacceptible performance hit on the application.
Sliding Window
--------------
Stength : No need to estimate the rate of packet traffic and optimize by
computing a sufficiently large sequence number span.
Weakness : Packets could be dropped, requiring a resynch by the application,
if they arrive too late.
If the window value becomes large, the amount of server memory
required to handle the book keeping could become large. The server could
limit the window values as it could with a window span, but again this might
not be appropriate for certain clients. Since the window slides both at
the bottom and the top in this approach (as opposed to just the bottom
in the fixed range approach), the amount of resources should be somewhat
less for a given packet generation rate and delay distribution.
===
The above analysis doesn't demonstrate one approach is significantly better
than the other. The only additional argument I will make for the sliding
window approach is it follows accepted practice in sequencing for reliable
transport and link-level protocols.
Dan
