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

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Aug 2009 01:15:12 -0500

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
--

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Aug 2009 12:36:16 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> 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[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby  guy");  [

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 11 Aug 2009 11:09:41 -0700

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 Aug 2009 13:06:08 -0500

>        INITIAL-CONTACT), and system W sees that has a broken latch.

Just one clarification: "system W's SA with system C expires" does not
mean that "system W sees that has a broken latch".  That's because the
current I-D says that latch breaks occur only as a result of conflicts;
dead peer detection does not cause latch breaks.

It might be useful to say that dead peer detection does cause latch
breaks now that we have chosen to reset faster, so to speak.  But I
wouldn't want to have to specify any specific timeouts, or, really, any
details of dead peer detection -- those would take time to work out.
Fortunately we could leave those details to IKEv2 and just add that "if
IKEv2 DPD concludes a given peer is dead then all latches with that peer
SHOULD be transitioned to the BROKEN state".

Possible wrinkle:

 - Is it possible for an off-path attacker to DoS IKEv2 between two
   peers?  If so then we must not allow DPD to cause latch breaks!

   DNS poisoning is not an issue here, but ICMP redirects and ARP
   spoofing are.  If you can spoof ARP you're on link, so that's not an
   issue.  And ICMP redirects should be getting ignored.  Any other ways
   to trigger IKEv2 DPD via an off-path attack?

My preference: leave the text as-is on this; don't allow DPD to break
latches, or perhaps allow it as a MAY, but not a SHOULD, much less a
MUST.

Rationale:

 a) there's a fairly strong distinction between "dead peer" and
    "SA/policy conflict", with the latter being an absolutely necessary
    cause of latch breaks while the former is not;
 b) it's easy to show that to cause such an SA conflict one must be
    on-path (or be able to spoof routing protocol updates) and policies
    must permit the conflict to arise (e.g., BTNS is in use), whereas
    it's harder to show the same for IKEv2 DPD -- we'd have to spend
    some time working that out;
 c) ULP/app timeout timers will generally result in DPD at the
    ULP/app layer anyways;
 d) we can always add DPD->latch break rules later if we need them,
    or we could let it be a MAY now and later upgrade it to SHOULD or
    even MUST if it proves useful.

Nico
--

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 12 Aug 2009 13:06:32 -0700

Nico,

Pls. see below.

>     even MUST if it proves useful.

Not sure I caught all the details of the discussion, but just to make sure I understand correctly: If a peer restarts, DPD will eventually detect it, and then the peers can proceed with re-establishing IKE and CHILD SAs. In the BTNS case where the BTNS IKE SA gets re-established after DPD, each of the BTNS peers can verify that they're talking to the same peer right? Thus I think the latches shouldn't be broken automatically when DPD concludes a peer is dead. They should only be broken in case it's not possible to re-establish a BTNS IKE SA after DPD, or a BTNS IKE SA can be established but to a different peer.

--julien

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Aug 2009 16:39:58 -0400

>>>>> "Julien" == Julien Laganier <Laganier> writes:
    Julien> Not sure I caught all the details of the discussion, but
    Julien> just to make sure I understand correctly: If a peer
    Julien> restarts, DPD will eventually detect it, and then the peers
    Julien> can proceed with re-establishing IKE and CHILD SAs. In the
    Julien> BTNS case where the BTNS IKE SA gets re-established after
    Julien> DPD, each of the BTNS peers can verify that they're talking
    Julien> to the same peer right? 

yes. The channel-binding information that would be maintained by at
least one of the peers (even if the application does not ask for it),
would indicate if it was the same peer.

    Julien> Thus I think the latches shouldn't
    Julien> be broken automatically when DPD concludes a peer is
    Julien> dead. They should only be broken in case it's not possible
    Julien> to re-establish a BTNS IKE SA after DPD, or a BTNS IKE SA
    Julien> can be established but to a different peer.

1) "not possible to re-establish a BTNS IKE SA after DPD"
this may be hard to define.

2) "BTNS IKE SA can be established but to a different peer."
this is easy to define, and we are all in agreement about this.
(And why treating it like a TCP RST may be appropriate)

For (1) the best we can do is to let the ULP timeout, I think.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 Aug 2009 16:38:08 -0500

On Wed, Aug 12, 2009 at 01:06:32PM -0700, Laganier, Julien wrote:
> Not sure I caught all the details of the discussion, but just to make
> sure I understand correctly: If a peer restarts, DPD will eventually
> detect it, and then the peers can proceed with re-establishing IKE and
> CHILD SAs. In the BTNS case where the BTNS IKE SA gets re-established
> after DPD, each of the BTNS peers can verify that they're talking to
> the same peer right? Thus I think the latches shouldn't be broken
> automatically when DPD concludes a peer is dead. They should only be
> broken in case it's not possible to re-establish a BTNS IKE SA after
> DPD, or a BTNS IKE SA can be established but to a different peer.

If a peer has restarted then, yes, we could immediately transition the
affected latches to BROKEN (without a way to get back to ESTABLISHED).
That's presuming that peer restart -> all connections to it are reset.
But there's no need to do this since the lack of valid SAs will quickly
be discovered, new SAs will be negotiated, and then TCP RSTs / SCTP
ABORTs will follow (there's no equiv for UDP though, so breaking UDP
latches in the case of peer restart makes sense).  We need to be careful
to distinguish restart of IKE daemon processes from peer reboots.

DPD also looks for peers that are simply not there anymore.  That's a
heuristic mechanism (liveness check -> <crickets for more than N seconds>
-> dead peer).  I'm not sure that it would be appropriate to let IKE
heuristically decide that a peer is dead when the ULP and app can do
that themselves.  In fact, I'd say that would not be appropriate.

OK, so I've convinced myself: we need not say anything about DPD, though
we could add that when peer restarts (reboots) are detected then all
affected latches SHOULD transition to BROKEN.

Nico
--