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

["Laganier, Julien" <julienl at qualcomm.com>]

Thanks Michael, Mike and Nico for working on resolving this issue. 

Unless someone objects to the proposed resolution below before end of the week, let's call it a WG consensus and publish an update of the draft accordingly.

--julien

> -----Original Message-----
> From: btns-bounces at ietf.org [mailto:btns-bounces at ietf.org] On Behalf Of
> Nicolas Williams
> Sent: Thursday, August 06, 2009 11:15 PM
> To: btns at ietf.org
> Cc: Eisler, Michael
> Subject: Re: [btns] Q: How to deal with connection latch breaks?
> 
> 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
> --
> _______________________________________________
> btns mailing list
> btns at ietf.org
> https://www.ietf.org/mailman/listinfo/btns