Re: [btns] Q: How to deal with connection latch breaks?

[Michael Richardson <[e-mail]>]

>>>>> "Nicolas" == Nicolas Williams <[e-mail]> writes:
    Nicolas> We believe that the purist approach to latch breaks in the
    Nicolas> absence of new APIs (or their non-use) is to treat the
    Nicolas> situation as packet loss.  However, the pragmatic default
    Nicolas> is to treat latch breaks as a reset (in the TCP case) or
    Nicolas> ICMP destination unreachable (in the SCTP case, when there
    Nicolas> are multi-homed end-points, so that path failover may take
    Nicolas> place sooner).

I wanted to post that I am in agreement, but it took me awhile to get
why TCP RESET makes sense sometimes.

The is the scenario. Assume a stable system (i.e. web server) (W), and an
end-point which is mobile (C).

C<->W do connection latching (perhaps facilitated by BTNS) and transfer
      some data. 
System C goes away (moves, shuts down, etc) from IP-C before it closes
       all it's TCP/SCTP sessions nicely.
System D is now at IP-D. 

Now, in the absense of BTNS, system W would send a TCP/SCTP segment to 
     IP-C, and system D would return with a TCP RST since it would not
     recognize the data.

Due to connection-latching, one of two things occur:
    1) system W sends TCP segments inside ESP, and system D sees it
       and has no idea what to do. (IKE-INITIAL-CONTACT could kill that
       SA, as could various birth-certificate proposals)

    2) system W's SA with system C expires (or is deleted by
       INITIAL-CONTACT), and system W sees that has a broken latch.

If system D is not doing IPsec (BTNS or otherwise), then the TCP/SCTP
just tries until the SA expires.  If the ULP times out, then it does
ETIMEOUT as it would when a cable is unplugged.

If system D is doing IPsec (BTNS), then system C recognizes that the SA
is broken to IP-C, and never sends anything. Since it never sends the
TCP segment, it never gets a TCP RST.  This is why is makes sense for an
implementation to pretend a TCP RST has been received if in fact the
latch is broken.

This is really an on-path TCP RST.

In the BGP situation, where TCP RSTs are of concern, this situation can
only occur if:
  a) one router (BGP-speaker) replaces another router at the same IP.
  b) the new router does IPsec/BTNS and system W is willing to permit
     the new router's key to assert the old router's IP.

(a) points to the fact that the IX has no layer-2/3 security. (i.e. ARP
    is insecure. Use SEND, or hard code ARP entries...)

(b) points to a misconfigured/unsecured PAD for this use.

Many in the BGP situation want to use BTNS to create the initial
relationships, and then lock the results down (which ceases to be BTNS)
via telephone/etc. communication.... 

-- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [e-mail] http://www.sandelman.ottawa.on.ca/ |device driver[
]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby  guy");  [