IP packets for a TCP connection taking multiple paths possible ? - TCP-IP

This is a discussion on IP packets for a TCP connection taking multiple paths possible ? - TCP-IP ; I recently saw a "dual WAN" series router from xincom ( www.xincom.com ). It has the capability to use two broadband connections going out to internet. Although I saw it working I did not get time to experiment much with ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: IP packets for a TCP connection taking multiple paths possible ?

  1. IP packets for a TCP connection taking multiple paths possible ?

    I recently saw a "dual WAN" series router from xincom ( www.xincom.com
    ). It has the capability to use two broadband connections going out to
    internet.
    Although I saw it working I did not get time to experiment much with
    it.
    Basically wanted to ask here if it is possible for the IP packets
    belonging to the same TCP connection, to take completely different
    routes.

    Even if it is possible theoretically, is it common for the ISPs to
    install TCP level filters in their network ? ( For instance if the
    network has not seen a SYN for a connection, and if they see a TCP
    data, will they drop the packet ? )

    Thanks
    --sony


  2. Re: IP packets for a TCP connection taking multiple paths possible ?

    In article <1156777341.726215.109150@h48g2000cwc.googlegroups. com>,
    wrote:
    >Basically wanted to ask here if it is possible for the IP packets
    >belonging to the same TCP connection, to take completely different
    >routes.


    Yes, definitely!!


    >Even if it is possible theoretically, is it common for the ISPs to
    >install TCP level filters in their network ? ( For instance if the
    >network has not seen a SYN for a connection, and if they see a TCP
    >data, will they drop the packet ? )


    Only at their aggregation points, that all the data comes through,
    and so which should have seen all of the relevant packets.

    It is not uncommon for businesses (and sometimes ISPs) to have
    "stateful" filtering of TCP packets, refusing to allow through
    conversations that start in the middle -- but this would only be
    done at places where it was reasonable to have seen all of the
    relevant traffic.


  3. Re: IP packets for a TCP connection taking multiple paths possible ?


    >
    > >Even if it is possible theoretically, is it common for the ISPs to
    > >install TCP level filters in their network ? ( For instance if the
    > >network has not seen a SYN for a connection, and if they see a TCP
    > >data, will they drop the packet ? )

    >
    > Only at their aggregation points, that all the data comes through,
    > and so which should have seen all of the relevant packets.
    >
    > It is not uncommon for businesses (and sometimes ISPs) to have
    > "stateful" filtering of TCP packets, refusing to allow through
    > conversations that start in the middle -- but this would only be
    > done at places where it was reasonable to have seen all of the
    > relevant traffic.


    Thanks for the fast response Walter :
    Looking at the documentation, the xincom router fixes on the broadband
    connection to use ( WAN1 or WAN2 ) at the initial 3 way handshake
    itself.
    But I was wondering what prevents one from making a dual wan router
    that decides on the WAN port on an IP packet level.
    Maybe it is the presence of the occasional ISPs ( who might drop a
    packet altogether, if they have not seen the previous TCP state as
    expected ), that forced xincom to design the router to do the load
    balancing at a TCP level rather than at the IP level.
    Thanks again
    --sony


  4. Re: IP packets for a TCP connection taking multiple paths possible?

    Hello,

    sonyantony@hotmail.com a écrit :
    >
    > Looking at the documentation, the xincom router fixes on the broadband
    > connection to use ( WAN1 or WAN2 ) at the initial 3 way handshake
    > itself.
    > But I was wondering what prevents one from making a dual wan router
    > that decides on the WAN port on an IP packet level.


    My guess is it is because some ISPs do source address filtering and drop
    any outgoing packet with a source address not belonging to the
    connection (=link) it originates, to prevent IP spoofing.
    In this case, as all outgoing packets of a TCP (or UDP, or whatever
    protocol) stream have the same source address, they must be routed
    through the same link.

  5. Re: IP packets for a TCP connection taking multiple paths possible ?

    In article <1156780106.803650.22920@m73g2000cwd.googlegroups.c om>, sonyantony@hotmail.com writes:
    > But I was wondering what prevents one from making a dual wan router
    > that decides on the WAN port on an IP packet level.


    Nothing at all. Here's a document that gives some details about Cisco's
    approach. It also touches on some potential issues that I haven't
    seen you mention.

    http://www.cisco.com/en/US/tech/tk36...80094820.shtml

    Note that there's nothing special about a WAN port in this regard.
    Load sharing between LAN ports or between a LAN port and a WAN port
    would work just the same.

  6. Re: IP packets for a TCP connection taking multiple paths possible ?


    Pascal Hambourg wrote:
    > Hello,
    >
    > sonyantony@hotmail.com a écrit :
    > >
    > > Looking at the documentation, the xincom router fixes on the broadband
    > > connection to use ( WAN1 or WAN2 ) at the initial 3 way handshake
    > > itself.
    > > But I was wondering what prevents one from making a dual wan router
    > > that decides on the WAN port on an IP packet level.

    >
    > My guess is it is because some ISPs do source address filtering and drop
    > any outgoing packet with a source address not belonging to the
    > connection (=link) it originates, to prevent IP spoofing.
    > In this case, as all outgoing packets of a TCP (or UDP, or whatever
    > protocol) stream have the same source address, they must be routed
    > through the same link.


    ( Sorry ) I doubt that to be the case.
    The router can always slap the source address of the WAN port from
    which the IP packet is sent out.
    In any case they are already doing this as this router does NAT.
    Did I miss your point ?
    --sony


  7. Re: IP packets for a TCP connection taking multiple paths possible?

    sonyantony@hotmail.com a écrit :
    >>
    >>>Looking at the documentation, the xincom router fixes on the broadband
    >>>connection to use ( WAN1 or WAN2 ) at the initial 3 way handshake
    >>>itself.
    >>>But I was wondering what prevents one from making a dual wan router
    >>>that decides on the WAN port on an IP packet level.

    >>
    >>My guess is it is because some ISPs do source address filtering and drop
    >>any outgoing packet with a source address not belonging to the
    >>connection (=link) it originates, to prevent IP spoofing.
    >>In this case, as all outgoing packets of a TCP (or UDP, or whatever
    >>protocol) stream have the same source address, they must be routed
    >>through the same link.

    >
    > ( Sorry ) I doubt that to be the case.
    > The router can always slap the source address of the WAN port from
    > which the IP packet is sent out.
    > In any case they are already doing this as this router does NAT.
    > Did I miss your point ?


    Yes you did : doing so would break TCP for sure, and probably any other
    kind of stream. As I said, the other end of the stream expects all
    packets to have the same source address.

  8. Re: IP packets for a TCP connection taking multiple paths possible ?


    > > ( Sorry ) I doubt that to be the case.
    > > The router can always slap the source address of the WAN port from
    > > which the IP packet is sent out.
    > > In any case they are already doing this as this router does NAT.
    > > Did I miss your point ?

    >
    > Yes you did : doing so would break TCP for sure, and probably any other
    > kind of stream. As I said, the other end of the stream expects all
    > packets to have the same source address.


    You are of course right. Didnt think of that at all.
    Hmm, then it turns out that all traffic from a given TCP connection
    should flow out from the same WAN port. And a per packet switching is
    not possible at all.

    --sony


  9. Re: IP packets for a TCP connection taking multiple paths possible ?

    In article <1156787435.977640.149850@m79g2000cwm.googlegroups. com>,
    sonyantony@hotmail.com wrote:

    > Pascal Hambourg wrote:
    > > Hello,
    > >
    > > sonyantony@hotmail.com a écrit :
    > > >
    > > > Looking at the documentation, the xincom router fixes on the broadband
    > > > connection to use ( WAN1 or WAN2 ) at the initial 3 way handshake
    > > > itself.
    > > > But I was wondering what prevents one from making a dual wan router
    > > > that decides on the WAN port on an IP packet level.

    > >
    > > My guess is it is because some ISPs do source address filtering and drop
    > > any outgoing packet with a source address not belonging to the
    > > connection (=link) it originates, to prevent IP spoofing.
    > > In this case, as all outgoing packets of a TCP (or UDP, or whatever
    > > protocol) stream have the same source address, they must be routed
    > > through the same link.

    >
    > ( Sorry ) I doubt that to be the case.
    > The router can always slap the source address of the WAN port from
    > which the IP packet is sent out.
    > In any case they are already doing this as this router does NAT.
    > Did I miss your point ?
    > --sony


    If you're doing NAT then you have to ensure that all the packets for a
    particular connection use the same translation. As a translation is
    associated with a particular WAN interface, you won't get per-packet
    decisions that the OP was concerned about.

    But if you're not doing NAT, the router won't make routing decisions
    based on the source address unless you explicitly put policy routing in
    its configuration. In this case, the potential problem isn't packets
    from the same connection taking multiple paths, but packets from ISP-1's
    address space going out through the ISP-2 connection. You either need
    to use policy routing or ensure that the ISP's don't filter based on the
    source addresses.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  10. Re: IP packets for a TCP connection taking multiple paths possible ?


    sonyantony@hotmail.com wrote:

    > Even if it is possible theoretically, is it common for the ISPs to
    > install TCP level filters in their network ? ( For instance if the
    > network has not seen a SYN for a connection, and if they see a TCP
    > data, will they drop the packet ? )


    It is rare and often foolish. That the ISP did not see a SYN for a
    connection does not mean that there wasn't one. For example, the SYN
    could have been encapsulated in an IPsec or SSL tunnel.

    ISPs generally do not and should not make the assumption that they can
    naively inspect and see all of their customer's traffic. (On the flip
    side, there are some ISPs that provide low-grade consumer service that
    specifically requires that they be able to see all your traffic, and
    they could filter in this way but rarely do so.)

    DS


  11. Re: IP packets for a TCP connection taking multiple paths possible ?


    sonyantony@hotmail.com wrote:

    > Thanks for the fast response Walter :
    > Looking at the documentation, the xincom router fixes on the broadband
    > connection to use ( WAN1 or WAN2 ) at the initial 3 way handshake
    > itself.
    > But I was wondering what prevents one from making a dual wan router
    > that decides on the WAN port on an IP packet level.
    > Maybe it is the presence of the occasional ISPs ( who might drop a
    > packet altogether, if they have not seen the previous TCP state as
    > expected ), that forced xincom to design the router to do the load
    > balancing at a TCP level rather than at the IP level.
    > Thanks again
    > --sony


    There are some common reasons, but I think it's basically a poor design
    decision to not offer a way around this.

    One reason is that splitting packets for a single TCP connection over
    multiple links can cause additional performance problems for TCP.
    Reception of packets out of order can cause performance issues for some
    TCP stacks.

    Another reason is that latency is generally better if a single
    connection cannot monopolize both links. However, in some cases all you
    care about is the throughput of that single connection.

    An unchangeable decision at TCP session establishment, however, has
    some huge problems. Consider if there are 10 TCP connections of varying
    load, 3 happen to get assigned to the same connection, the other 7
    close, and those 3 are maxed out for a long time.

    DS


  12. Re: IP packets for a TCP connection taking multiple paths possible ?

    In article <1156851352.280692.205830@i3g2000cwc.googlegroups.c om>,
    David Schwartz wrote:

    >sonyantony@hotmail.com wrote:


    >> Even if it is possible theoretically, is it common for the ISPs to
    >> install TCP level filters in their network ? ( For instance if the
    >> network has not seen a SYN for a connection, and if they see a TCP
    >> data, will they drop the packet ? )


    >It is rare and often foolish. That the ISP did not see a SYN for a
    >connection does not mean that there wasn't one. For example, the SYN
    >could have been encapsulated in an IPsec or SSL tunnel.


    There is no provision in IPSec to send TCP packets direct or tunneled
    according to their state, only according to their layer 4 information.
    If a packet manages to "escape" and go directly, then it *should* be
    rejected, as it is not going to have the appropriate authentication
    layers.

  13. Re: IP packets for a TCP connection taking multiple paths possible ?


    Walter Roberson wrote:

    > >It is rare and often foolish. That the ISP did not see a SYN for a
    > >connection does not mean that there wasn't one. For example, the SYN
    > >could have been encapsulated in an IPsec or SSL tunnel.


    > There is no provision in IPSec to send TCP packets direct or tunneled
    > according to their state, only according to their layer 4 information.
    > If a packet manages to "escape" and go directly, then it *should* be
    > rejected, as it is not going to have the appropriate authentication
    > layers.


    Rejected by the recipient, who can determine that the packet violates
    their security policy. It should not be discarded by an intermediate
    machine that has no way of knowing.

    Unidirectional tunnels to deal with zealous spoof filtering is not that
    uncommon, for example. This causes an ISP to see packets in one
    direction but not the packets in the other direction (because they are
    in the tunnel).

    DS


  14. Re: IP packets for a TCP connection taking multiple paths possible ?

    In article <1156906817.196652.286130@m73g2000cwd.googlegroups. com>,
    David Schwartz wrote:

    >Walter Roberson wrote:


    >> >It is rare and often foolish. That the ISP did not see a SYN for a
    >> >connection does not mean that there wasn't one. For example, the SYN
    >> >could have been encapsulated in an IPsec or SSL tunnel.


    >> There is no provision in IPSec to send TCP packets direct or tunneled
    >> according to their state, only according to their layer 4 information.


    >Unidirectional tunnels to deal with zealous spoof filtering is not that
    >uncommon, for example. This causes an ISP to see packets in one
    >direction but not the packets in the other direction (because they are
    >in the tunnel).


    If an ISP did not see a SYN for a TCP connection, then it is not an
    instance of unidrectional tunnels. If traffic is seen in one direction
    but not the other, then the ISP will see either the SYN or the SYN ACK .
    If a TCP packet with neither is seen then it was forged or leaked
    (or was part of a previous connection that there is no longer state
    information for.)

  15. Re: IP packets for a TCP connection taking multiple paths possible ?


    Walter Roberson wrote:

    > If an ISP did not see a SYN for a TCP connection, then it is not an
    > instance of unidrectional tunnels. If traffic is seen in one direction
    > but not the other, then the ISP will see either the SYN or the SYN ACK .
    > If a TCP packet with neither is seen then it was forged or leaked
    > (or was part of a previous connection that there is no longer state
    > information for.)


    This is just taking a bunch of assumptions and lining them up to a
    conclusion.

    An ISP, in general, has no idea what the meaning of its customers'
    traffic is.

    Two people could, if they wanted to, invert the meaning of the SYN flag
    in all the TCP traffic between their two sites. They could agree to
    send all SYNs through a tunnel but not packets without SYN bits set.

    For an ISP to assume that it understood what the strictly end-to-end
    bits of its customers' traffic meant would break a large number of
    perfectly legitimate applications.

    There are a number of documented cases of exactly this happening. For
    example, the current window scaling problems occured because ISPs
    assumed they could correctly understand the meaning of the window size
    numbers in TCP packets passing through their routers. Unbeknownst to
    them, a TCP option changes the meaning of those sizes.

    What happens if a new TCP option tomorrow changes the meaning of the
    SYN flag?

    DS


  16. Re: IP packets for a TCP connection taking multiple paths possible ?

    In article <1156980987.314948.157840@i3g2000cwc.googlegroups.c om>,
    David Schwartz wrote:

    >What happens if a new TCP option tomorrow changes the meaning of the
    >SYN flag?


    That isn't going to happen. There is *far* too much filtering going
    on that relies on the SYN flag continuing to have its current
    meaning.

    >Two people could, if they wanted to, invert the meaning of the SYN flag
    >in all the TCP traffic between their two sites. They could agree to
    >send all SYNs through a tunnel but not packets without SYN bits set.


    Not using IPSec they couldn't. IPSec does not allow you to get that
    granular.


    >For an ISP to assume that it understood what the strictly end-to-end
    >bits of its customers' traffic meant would break a large number of
    >perfectly legitimate applications.


    Like, for example, the way that port numbers are "strictly end-to-end
    bits", and yet it is not only common but recommended that ISPs block
    some ports (e.g., outgoing SMTP that doesn't go through a
    residential ISP's official servers.)

  17. Re: IP packets for a TCP connection taking multiple paths possible ?


    Walter Roberson wrote:

    > In article <1156980987.314948.157840@i3g2000cwc.googlegroups.c om>,
    > David Schwartz wrote:


    > >What happens if a new TCP option tomorrow changes the meaning of the
    > >SYN flag?


    > That isn't going to happen. There is *far* too much filtering going
    > on that relies on the SYN flag continuing to have its current
    > meaning.


    Assumptions like that get us into trouble.

    > >Two people could, if they wanted to, invert the meaning of the SYN flag
    > >in all the TCP traffic between their two sites. They could agree to
    > >send all SYNs through a tunnel but not packets without SYN bits set.


    > Not using IPSec they couldn't. IPSec does not allow you to get that
    > granular.


    You mean some IPSec implementations don't.

    > >For an ISP to assume that it understood what the strictly end-to-end
    > >bits of its customers' traffic meant would break a large number of
    > >perfectly legitimate applications.


    > Like, for example, the way that port numbers are "strictly end-to-end
    > bits", and yet it is not only common but recommended that ISPs block
    > some ports (e.g., outgoing SMTP that doesn't go through a
    > residential ISP's official servers.)


    They understand that that breaks some things that they don't wish to
    break. You, on the other hand, seem to be insisting that it can't break
    anything. That is what is wrong.

    DS


+ Reply to Thread