RE: [fw-wiz] IPSEC over load-shared T1s (per packet)

From: R. DuFresne (dufresne_at_sysinfo.com)
Date: 09/19/03

  • Next message: Ben Nagy: "RE: [fw-wiz] IPSEC over load-shared T1s (per packet)" 
    To: Ben Nagy <ben@iagu.net>
Date: Fri, 19 Sep 2003 11:32:11 -0400 (EDT)

    I might be reading Ben wrong, but, I get the impression he is talking
    about session concerency? A 'sticky' bit in the load balancer end, such
    that a session started and sent via one t1 remains directed through that
    path for the remainder of the session?

    Thanks,

    Ron DuFresne

    On Thu, 18 Sep 2003, Ben Nagy wrote:

    > ObBOFH: One of the T1 RJ connectors must be dirty, which is causing packet
    > corruption. Give both the telco jacks a good clean (licking them works well)
    > and see if that fixes the problem. [1]
    >
    > Seriously, I do have a theory ;)
    >
    > Does this routing guarantee to preserve sequencing?
    >
    > If it's really as you described (packets send one for one via alternate
    > links) then you have some potential problems brewing, I think.
    >
    > TCP will "work things out" when packets arrive out of sequence, but with
    > IPSec it's left up to the implementation. One security concern with most
    > crypto things is replay protection. IPSec addresses this by using a
    > mandatory sequence number in the ESP header. The receiveing IPSec doesn't
    > _have_ to take any notice, but most do. If your receiving IPSec has enabled
    > replay protection then if one link is going faster half the packets are
    > going to get dropped (sequence number < current).
    >
    > This would make your tunneled protocol (say TCP) do the retransission thing,
    > so it would work itself out eventually, but the speed would indeed suffer
    > horribly.
    >
    > See if you can convince your router to preserve "IP flows" and use the two
    > links in a more sensible manner. That might help.
    >
    >
    >
    > Best of luck,
    >
    > ben
    >
    > PS: Let us know when you work it out? This is an interesting one.
    >
    > [1] The RJ's are live, for non-network-engineer types. Not enough to kill
    > you, but it hurts. :)
    >
    > > -----Original Message-----
    > > From: firewall-wizards-admin@honor.icsalabs.com
    > > [mailto:firewall-wizards-admin@honor.icsalabs.com] On Behalf
    > > Of TSimons@Delphi-Tech.com
    > > Sent: Thursday, September 18, 2003 3:38 AM
    > > To: firewall-wizards@honor.icsalabs.com
    > >
    > > Hello All
    > >
    > > Recently we doubled our internet bandwith to two T1s from the
    > > same provider
    > > that terminate on in the same router on the NOC side.
    > >
    > > We setup IP LOAD-SHARING PER-PACKET on each of the serial
    > > links on both
    > > sides (NOC and Us) in order to get an aggregate 3.0mbit.
    > > PER-PACKET routing
    > > alternates usage of the T1s, one for one...
    > >
    > > Since then, VPN performance has taken a dive. Sniffing out
    > > traffic, ESP
    > > packets are sent 3-4 times before they can be properly decrypted.
    > >
    > > Someone along the way said that using PER-PACKET routing
    > > changes the CRC
    > > value of the packets. Is this correct, has anyone else seen
    > > this issue? I
    > > can't see how the CRC is changed, the hop count isn't
    > > changing, the lines
    > > are identical, and they terminate in the same router, so the
    > > last hop is the
    > > F0/0 interface of the router before getting to the firewall.
    > >
    > > Thanks,
    > > ~Todd
    > >
    > > __________________________________
    > > Todd M. Simons
    > > Senior MIS Engineer
    > > Dell Tier 1 PA Technician
    > > Delphi Technology, Inc.
    > > New Brunswick, NJ
    >
    > _______________________________________________
    > firewall-wizards mailing list
    > firewall-wizards@honor.icsalabs.com
    > http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
    > 

    -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior security consultant:  sysinfo.com
                        http://sysinfo.com
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
                -- Johnny Hart
testing, only testing, and damn good at it too!
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
  • Next message: Ben Nagy: "RE: [fw-wiz] IPSEC over load-shared T1s (per packet)"

    Relevant Pages

    • RE: [fw-wiz] IPSEC over load-shared T1s (per packet)
      ... The packets were being sent over alternating links in strict round-robin, ... which meant that the ESP packets sometimes arrived out of sequence. ... > that a session started and sent via one t1 remains directed ... >> IPSec it's left up to the implementation. ...
      (Firewall-Wizards)
    • Re: IP Spoofing
      ... That would be enough if the purpose of the request was e.g. to delete a database by SQL injection. ... You would not need to keep it in 7 packets, merely to send in a TCP window - pretty large these days, BUT you would also need to cut in on an existing ESTABLISHED session. ... it is quite possible to send packets to the server without anything. ...
      (comp.lang.php)
    • Re: just an idea for packet protocol using ECB
      ... >> packets may be lost. ... the system would never shutdown if attackers kept ... The damage an attacker ... So each file transmission gets a session number. ...
      (sci.crypt)
    • Re: IP Spoofing
      ... That would be enough if the purpose of the request was e.g. to delete a database by SQL injection. ... You would not need to keep it in 7 packets, merely to send in a TCP window - pretty large these days, BUT you would also need to cut in on an existing ESTABLISHED session. ... it is quite possible to send packets to the server without anything. ...
      (comp.lang.php)
    • Re: Remote desktop deadlock on XP SP2
      ... I'm going to move all packet processing out of usermode. ... forward packets from our NDIS IM to usermode via an inverted call ... TermSrv.dll creates a new session for the purpose of displaying the logon ... lives on a DPC routine for the network miniport ...
      (microsoft.public.win32.programmer.kernel)