RE: IPSEC over load-shared T1s (per packet)

[TSimons () Delphi-Tech com]

Mikael-
We're actually investigating Multilink PPP on our external Cisco Router to
the ISP as a solution:
http://www.cisco.com/warp/public/cc/pd/ifaa/pa/much/tech/althb_wp.pdf

I will check back with the firewall vendor too.

Thanks,
~Todd

-----Original Message-----
From: Mikael Olsson [mailto:mikael.olsson () clavister com]
Sent: Friday, September 19, 2003 2:18 PM
To: TSimons () Delphi-Tech com
Cc: Ben Nagy; fw-wiz
Subject: Re: [fw-wiz] IPSEC over load-shared T1s (per packet)



Ben Nagy wrote:
> The packets were being sent over alternating links in strict round-robin,
> which meant that the ESP packets sometimes arrived out of sequence. The
> IPSec implementation was dropping all the ones with seq < currentseq,
which
> was causing retransmits in the tunneled TCP sessions.

I'm thinking $vendor should fix their code. Keeping track of which of 
the past n segments have or have not arrived is not rocket science, 
and it allows out-of-order delivery without packet loss.

> From RFC2401:

      o Anti-Replay Window: a 32-bit counter and a bit-map (or
        equivalent) used to determine whether an inbound AH or ESP
        packet is a replay.
        [REQUIRED for all implementations but used only for inbound
        traffic. NOTE: If anti-replay has been disabled by the
        receiver, e.g., in the case of a manually keyed SA, then the
        Anti-Replay Window is not used.]

The "bit-map" they're talking about is the same thing I was 
talking about. I say re-open the ticket. Reordering happens.
Implementations that do not take that into account are broken.

-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards