Re: proposal: TCP rendevous

From: Daniel Hartmeier (daniel_at_benzedrine.cx)
Date: 11/28/05

  • Next message: Ruslan Ermilov: "Re: parallelizing ipfw table" 
    Date: Mon, 28 Nov 2005 00:37:48 +0100
To: Julian Elischer <julian@elischer.org>

    On Sun, Nov 27, 2005 at 02:21:02PM -0800, Julian Elischer wrote:

    > yes, which means it might unexpectedly fail.

    I don't see how it can be done with TCP, assuming both peers are behind
    NATing firewalls (like pf).

    Some tricks to consider are:

    Let one peer send a SYN through the firewall towards the other peer, but
    set the TTL low, so the firewall creates a state entry but there will be
    no RST from the peer tearing down the state entry (the TTL-exceeded ICMP
    error is not a problem).

    The NATing firewall will pick a random source port as replacement and
    might even randomize the sequence numbers (as in pf's "modulate state").
    Can the first peer find out what source port and ISN was chosen, so it
    can relay the information to an external third party?

    One idea would be to craft an ICMP error sent by the first peer, say a
    fake TTL-excceded message. In the inner IP and TCP header (the one in
    the ICMP payload), pretend that the first peer received a SYN+ACK from
    the second peer, and that the second peer chose the very same ISN as the
    first peer. But in the outer IP header, set the destination address to
    the external third party. This would pass pf's state engine and pf would
    demodulate the sequence number quoted in the payload. Hence, the
    external third party would receive both the random source part and the
    externally visible ISN of the first peer. It could then relay that
    information to the second peer.

    But here comes the problem. The second peer could similarly send a
    low-TTL SYN to create a state entry on his firewall, and then pass out a
    SYN+ACK to the first peer's port and ack'ing the proper ISN. But the
    firewall would similarly pick a random source port replacement for the
    second peer, which wouldn't match what the first peer picked as initial
    destination port.

    In short, the random NAT source ports are only decided when the first
    packet is sent. But the first packet already needs to contain the other
    peer's port.

    Which puts us back to square one ;)

    Daniel
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Ruslan Ermilov: "Re: parallelizing ipfw table"

    Relevant Pages

    • Re: vpn redundancy PIX and 3000 series
      ... >they can vpn into a pix525 firewall, and if the internet connection the ... "The peer that packets are actually sent to is determined by the last ...
      (comp.dcom.sys.cisco)
    • Re: Zonealarm and LinkSys DSL/Cable Router
      ... security and peer to Peer are mutually excluding. ... I'm using a LinkSys BEFSR41 DSL/Cable Router and both machines are ... I need to know how to keep the ZA firewall up and ... Outgoing mail is certified Virus Free. ...
      (comp.security.firewalls)
    • Re: Peer to Peer file sharing using WidowsXP accross the internet
      ... I am able to ping the peer PC. ... I installed the netbeui protocol to see if ... I have both the tcp/ip and the ... You need a firewall in place, even if it isn't the Windows firewall. ...
      (microsoft.public.windowsxp.network_web)
    • Re: Globally prevent users from downloading certain files
      ... That depends on what firewall, ... gateway you're running at your Internet gateway, ... you can block downloads for common transfer protocols like HTTP, FTP, ... SMTP, NNTP and peer to peer, but users might still be able to download ...
      (microsoft.public.win2000.security)
    • Re: Access denied
      ... of the XP peer but when I try to open one of the directories on the XP ... > Access denied is your only error message and nothing in the log? ... > If the credentials are correct, is the firewall enabled? ... without even the implied warranty of merchantability ...
      (microsoft.public.win2000.networking)