<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: cipe-l <cipe-l,AT,inka,DOT,de>
Subject: Re: Replays - thoughts on Gutmann response
From: Mr Allwyn Fernandes <af+cipel,AT,stobor,DOT,net>
Date: Thu, 9 Oct 2003 03:08:10 +1000
In-reply-to: <002e01c38dba$d0fb7600$d100010a@lyta>
References: <002e01c38dba$d0fb7600$d100010a@lyta>

Here's the IPSEC RFC, http://www.rfc-editor.org/rfc/rfc2401.txt
which says "Note: Appendix C contains sample code for a bitmask check 
for a 32 packet window that can be used for implementing anti-replay 
service." (Appendix C reproduced below...)

My understanding of the code (and the RFC) is that it accepts packets 
which are have a sequence number at most 32(!!!) less than the most 
recently seen packet, and not set as "seen" in the sequence bitmask...

As far as running the KX inside the stream, we would still have to 
encrypt the KX stream... (Mark, you didn't say you wouldn't encrypt it, 
but I just wanted to make it explicit...) As others have stated, if a 
session key is broken, we need to prevent future session keys from 
being compromised. Using the dynamic session key as the only encryption 
on the KX packets is not an option. Maybe a TLS stream in the tunnel? 
(Nah... don't want to use certificates...) Double-encrypted: static-key 
encrypt, packetise for delivery, then dynamic-key encryption? 



Appendix C -- Sequence Space Window Code Example

   This appendix contains a routine that implements a bitmask check for
   a 32 packet window.  It was provided by James Hughes
   (jim_hughes,AT,stortek,DOT,com) and Harry Varnis 
   and is intended as an implementation example.  Note that this code
   both checks for a replay and updates the window.  Thus the algorithm,
   as shown, should only be called AFTER the packet has been
   authenticated.  Implementers might wish to consider splitting the
   code to do the check for replays before computing the ICV.  If the
   packet is not a replay, the code would then compute the ICV, (discard
   any bad packets), and if the packet is OK, update the window.

#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;

enum {
    ReplayWindowSize = 32

u_long bitmap = 0;                 /* session state - must be 32 bits */
u_long lastSeq = 0;                     /* session state */

/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);

int ChkReplayWindow(u_long seq) {
    u_long diff;

    if (seq == 0) return 0;             /* first == 0 or wrapped */
    if (seq > lastSeq) {                /* new larger sequence number */
        diff = seq - lastSeq;
        if (diff < ReplayWindowSize) {  /* In window */
            bitmap <<= diff;
            bitmap |= 1;                /* set bit for this packet */
        } else bitmap = 1;          /* This packet has a "way larger" */
        lastSeq = seq;
        return 1;                       /* larger is good */
    diff = lastSeq - seq;
    if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
    if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
    bitmap |= ((u_long)1 << diff);              /* mark as seen */
    return 1;                           /* out of order but good */

char string_buffer[512];
#define STRING_BUFFER_SIZE sizeof(string_buffer)

int main() {
    int result;
    u_long last, current, bits;

    printf("Input initial state (bits in hex, last msgnum):\n");
    if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
    sscanf(string_buffer, "%lx %lu", &bits, &last);
    if (last != 0)
    bits |= 1;
    bitmap = bits;
    lastSeq = last;
    printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
    printf("Input value to test (current):\n");

    while (1) {
        if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
        sscanf(string_buffer, "%lu", &current);
        result = ChkReplayWindow(current);
        printf("%-3s", result ? "OK" : "BAD");
        printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
    return 0;

On Thu, 9 Oct 2003 02:40, Mark Smith wrote:
> > The paper suggests using the sliding-window technique for replay
> > protection... (as used in IPSEC and OpenVPN)... This
> > addresses Allan's
> > concerns about how to simultaneously allow out-of-sequence packets,
> > while preventing problems with duplicates...
> Thank you, that's precisely what I've been looking for.  This is
> exactly the solution I was trying to describe.
> Although it does detect duplicates or replay, within the time frame
> or not, I've got a niggling thought about how you slide the window
> when the start actually refers to a dropped packet.  I've rewritten
> this bit a few times now trying to explain what I mean, I'm wondering
> now if I'm assuming something that's wrong, so bear with me while I
> attempt to explain myself, even if only for my own benefit =)
> I've worked through a couple of simple examples with regards a simple
> window consisting of start and end packet, storing both the packet
> number and the time.  This method suffers if multiple packets arrive
> out of order or are dropped.  If, however, we maintain a fixed size
> buffer using head and tail, we can easily cope with this, ignore
> packets that are too old, or if we're processing high bandwidth,
> packets that haven't arrived within the time it takes to cycle the
> buffer once, perhaps 200 packets as an example buffer size?  Could be
> configurable with a default if desired.
> This latter solution allows for the use of sequence numbers, which
> gives us detection of duplicate packets, whether they're replayed or
> injected.  It does rely on the sequence number remaining secure
> within the packet, but I'm hoping someone else has thought that
> through.
> Message deletion has zero impact on the data stream, only on KX.  I'm
> still thinking about how to strengthen KX, I've had an evil idea of
> using a TCP stream actually inside the tunnel.  Specifically the two
> daemons connect to each other via TCP using the tunnel endpoint
> addresses, which the OS should route correctly through the tunnel. 
> That way KX not only looks like tunnel traffic, it really is.  The
> difficulty is in working out which way it should connect, which could
> be overcome by having two channels.  This has the added benefit of
> allowing a protocol extension for the scripting idea that someone
> came up with.
> Please, feel free to tell me why this wouldn't work, but I can't seem
> to find a problem based on my knowledge of the protocol.  If I had
> the time, I'd be working on this already.
> Any other news on any of this?  Any news about mailing lists yet?
> Take care, and stay happy,

Allwyn Fernandes
Stobor Pty Ltd

Mobile: + 61 414 470 392
Email: af+cipel,AT,stobor,DOT,net
Web: http://stobor.net/

<< | Thread Index | >> ]    [ << | Date Index | >> ]