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

[Nicolas Williams <[e-mail]>]

Michael Richardson, Mike Eisler and I have discussed this issue in
e-mail and on the phone and we have come to a consensus.

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

The pragmatic approach allows an on-path DoS, but not an off-path DoS.
This seems acceptable given that an on-path attacker that can pull off a
connection reset attack by causing a latch break can also cause bits to
stop moving in the "purist" alternative anyways.  I.e., there's an
on-path DoS attack not matter what, and resetting the connection
(or causing failover to another path) sooner seems better than forcing
the ULP or the application to timeout first.

So we will say that implementors SHOULD provide APIs and MUST choose a
default behavior in case of latch breaks when no APIs are available (or
can't be used), and we list the set of behaviors that implementors may
choose from.  We also specify a default behavior: the "pragmatic"
one described above.  Finally, we combine the relevant text from
sections 5.1 and 5.4 into a single new section.

The new text, to replace the last paragraph of sections 5.1 and 5.4:

   See section 5.5.

New section 5.5 text (modulo xml2rfc formatting):

5.5 Handling of BROKEN state for TCP and SCTP

   There are several ways to handle connection latch transitions to the
   BROKEN state in the case of connection-oriented ULPs like TCP or
   SCTP:

   a) Wait for a possible future transition back to the ESTABLISHED
      state, until which time the ULP will not move data between the two
      end-points of the connection.  ULP and application timeout
      mechanisms will, of course, trigger in the event of too lengthy a
      stay in the BROKEN state.  SCTP can detect these timeouts and
      initiate failover, in the case of multi-homed associations.

   b) Act as though the connection has been reset (RST message
      received, in TCP, or ABORT message received, in SCTP).

   c) Act as though an ICMP destination unreachable message had been
      received (in SCTP such messages can trigger path failover in the
      case of multi-homed associations).

   Implementors SHOULD provide APIs for either informing applications
   (asynchronously or otherwise) of latch breaks, so that they may
   choose a disposition (wait, close, or proceed with path failover), or
   by which applications can select a specific disposition a priori
   (before a latch break happens).

   Implementors MUST provide a default disposition in the event of a
   connection latch break.  Though (a) is clearly the purist default, we
   RECOMMEND (b) for TCP and SCTP associations where only a single path
   remains (one 5-tuple), and (c) for multi-homed SCTP associations.
   The rationale for this recommendation is as follows: a conflicting SA
   most likely indicates that the original peer is gone and has been
   replaced by another, and it's not likely that the original peer will
   return, thus failing faster seems reasonable.

   Note that our recommended default behavior does not create off-path
   reset denial-of-service (DoS) attacks: to break a connection latch an
   attacker would first have to successfully establish an SA, with one
   of the connection's end-points, that conflicts with the connection
   latch, and that requires multiple messages to be exchanged between
   that end-point and the attacker.  Unless the attacker's chosen victim
   end-point allows the attacker to claim IP address ranges for its SAs
   then the attacker would have to actually take over the other
   end-point's addresses, which rules out off-path attacks.

Comments?

Nico
--