Subject: [Dots] Acceptable Signal Loss ?

From: Flemming Andreasen <[email-masked]>
Date: Mon, 13 Mar 2017 21:40:31 -0400

The requirement document says:

<quote>

    DM-007:  Acceptable Signal Loss Representation: The data model MUST
       be able to represent the DOTS agent's preference for acceptable
       signal loss when establishing a signaling session, as described in
       GEN-002.
</quote>

Can somebody elaborate on this point ? If we assume the signal channel 
is not reliable to begin with and messages are not acknowledged, then 
what does this mean ?

What will each side do with this, let alone find a way of satisfying it 
? For example, will the DOTS server stop any current mitigation if it 
somehow discovers that the signal loss is now too high ?

Thanks

-- Flemming

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 14 Mar 2017 09:01:03 +0700

On 14 Mar 2017, at 8:40, Flemming Andreasen wrote:

> For example, will the DOTS server stop any current mitigation if it 

One would hope not . . .

To be pedantic, DOTS servers (within the context of DOTS itself) don't 
actually stop or start mitigations, per se.  They *signal for* these 
actions - whether it's to services on-board the DOTS servers themselves 
or to entirely separate hosts/services/systems.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Tue, 14 Mar 2017 03:04:21 +0000

On Mar 13, 2017, at 9:40 PM, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:

<quote>

Can somebody elaborate on this point ? If we assume the signal channel is not reliable to begin with and messages are not acknowledged, then what does this mean ?

What will each side do with this, let alone find a way of satisfying it ?

Think of this in terms of the session health monitoring requirement. It’s allowed, even expected, that some heartbeats won’t get through from time to time. How many consecutive lost heartbeats are tolerable before a DOTS agent decides its peer is unreachable?

In the architecture draft, we discuss using this signal loss detection as a trigger for mitigation, under Automated Mitigation on Loss of Signal:

   While [I-D.ietf-dots-requirements] specifies the DOTS protocol be
   robust when signaling under attack conditions, there are nevertheless
   scenarios in which the DOTS signal is lost in spite of protocol best
   efforts.  To handle such scenarios, a DOTS client operator may
   configure the signaling session to trigger mitigation when the DOTS
   server ceases receiving DOTS client signals (or vice versa) beyond
   the miss count or period permitted by the protocol.

I think the more general case here would be an alert to the local operators.

For example, will the DOTS server stop any current mitigation if it somehow discovers that the signal loss is now too high ?

Since we’ve described using signal loss as a mitigation trigger in the architecture draft, it certainly makes no sense to me to use it as an excuse to stop mitigation. Neither does it make sense to let the mitigation remain in place forever if the requesting client—or another client with equivalent credentials—never comes back online. Mitigation lifetimes would mean the existing mitigation continues for the remainder of the lifetime (barring the corner cases where signal is lost at or near mitigation lifetime expiration).

Maybe a reasonable thing to do on signal loss during mitigation is to permit the DOTS server to extend the mitigation by half the expiring lifetime, then half of that half (with a reasonable floor value), and so on up to a configured duration or while the attack is above a certain scale? It seems like there’d need to be mutual understanding of the strategy when setting up the signal channel.

andrew