Subject: Re: [Dots] requirements clarifications needed

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 02:45:16 +0000

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
> Sent: Monday, March 21, 2016 10:11 PM
> To: dots
> Subject: Re: [Dots] requirements clarifications needed
> 
> On 20 Mar 2016, at 21:44, Andrew Mortensen wrote:
> > 3. Whether reduced fate sharing warrants a requirement, as raised in
> > [3].
> 
> Avoidance of fate-sharing should be an operational recommendation, and
> the protocol itself and messaging should lend themselves to such to the
> degree that it is practicable, IMHO.

Why would the DOTS agents IP addresses/ports change during the attack ?
Though there is binding to a 5-tuple, (D)TLS allows session resumption.

> 
> > 4. Whether a DOTS server SHOULD be able to redirect a DOTS client to
> > another DOTS server [4].
> 
> Yes, given proper bidirectional authentication, IMHO.

Redirecting the DOTS client to another DOTS server should be avoided during attack time, re-direction may incur multiple roundtrips before DOTS signal can be conveyed to the DOTS server. 
How does the old DOTS server ensure that the new DOTS server to which the client is re-directed does not further re-direct the client 
(avoid endlessly re-directing the DOTS client) ?

-Tiru

> 
> -----------------------------------
> Roland Dobbins <[email-masked]>
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 23 Mar 2016 10:14:29 +0700

> Though there is binding to a 5-tuple, (D)TLS allows session 

Due to a DDoS attack, perhaps?

;>

Or a power failure, or . . . ?

All the usual BCPs should be implemented to protect DOTS communications 
channels.  Nevertheless, the idea of a DOTS 'session' or 'conversation' 
or 'thread-ID' or whatever would de-conflate DOTS messaging itself from 
layer-3 node EIDs, and I think that would be a Good Thing.

> Redirecting the DOTS client to another DOTS server should be avoided 
> during attack time

Why?

> re-direction may incur multiple roundtrips before DOTS signal can be 
> conveyed to the DOTS server.

And what if this is necessary, for some reason?

We should not be enforcing operational practice straitjackets on DOTS 
users via arbitrary constraints, IMHO.

> How does the old DOTS server ensure that the new DOTS server to which 
> the client is re-directed does not further re-direct the client (avoid 
> endlessly re-directing the DOTS client) ?

It's quite possible that multiple redirects might be necessary.

Anything has the potential to be pathological, given human or 
machine/code error.  That alone isn't a reason to disallow potentially 
operationally-useful functionality, IMHO.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2016 23:35:14 -0400

> Though there is binding to a 5-tuple, (D)TLS allows session resumption.

A mobile target, though how such a one can be targetted is interesting.  
The attack would have to be against a whole range of addresses.  Or more 
likely a cable connection that due to the attack bounces and assigns a 
new address.  That makes more sense.  Perhaps the cable ISPs can add here.

> (avoid endlessly re-directing the DOTS client) ?

And as I said to you and Andy, how is the security state maintained?  Is 
it duplicated ahead of this event?  Does a new security state need to be 
negotiated at a time where such a negotiation is likely to fail?  So I 
also wonder how this works.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 05:07:53 +0000

> Sent: Wednesday, March 23, 2016 8:44 AM
> To: dots

If there is no binding then the DOTS agent can receive any DOTS message from any IP address and will have to defend from various new attacks that (D)TLS, IPSEC etc. don't face today. Security protocols are flexible to support session resumption where client moves from one IP address to another for mobility.

> > Redirecting the DOTS client to another DOTS server should be avoided

Let's say if TCP is used for DOTS signaling channel, DOTS signal can only be sent by the client after the TCP handshake complete and TLS session is resumed.

> And what if this is necessary, for some reason ?

What are those reasons and is there a way to avoid re-direction during attack ?

> 
> We should not be enforcing operational practice straitjackets on DOTS users
> via arbitrary constraints, IMHO.
> 

If multiple redirects happen then it potentially impacts the time to start the DDOS mitigation.

> 
> Anything has the potential to be pathological, given human or machine/code
> error.  That alone isn't a reason to disallow potentially operationally-useful
> functionality, IMHO.

How multiple re-directs are operationally useful is yet to be seen and discussed in the WG ?

-Tiru

---

From: <[email-masked]>
Date: Wed, 23 Mar 2016 06:54:35 +0000

Hi Tiru, 

Redirecting a client to another server is a useful functionality for various operational reasons: e.g., the server instance is overloaded, redirect the client to a service-specific server (e.g., telephony), etc.

How redirection is triggered, is policy-based and deployment-specific. 

How redirection is actually designed, is out of scope of the requirements document. That discussion should be left to solution document(s), IMHO. In particular, how redirection should be designed to avoid spirals/loops, etc. should be part of that space.

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Tirumaleswar Reddy
> (tireddy)
> Envoyé : mercredi 23 mars 2016 03:45
> À : Roland Dobbins; dots
> Objet : Re: [Dots] requirements clarifications needed
> 
> during attack time, re-direction may incur multiple roundtrips before DOTS
> signal can be conveyed to the DOTS server.
> How does the old DOTS server ensure that the new DOTS server to which the
> client is re-directed does not further re-direct the client

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 23 Mar 2016 21:25:13 +0700

On 23 Mar 2016, at 12:07, Tirumaleswar Reddy (tireddy) wrote:

> Security protocols are flexible to support session resumption where 
> client moves from one IP address to another for mobility.

Right - which means this isn't a barrier to redirection.

> Let's say if TCP is used for DOTS signaling channel, DOTS signal can 
> only be sent by the client after the TCP handshake complete and TLS 
> session is resumed.

So?

> What are those reasons and is there a way to avoid re-direction during 

Mohamed already touched on some of them.

> start the DDOS mitigation.

Yes, and . . . ?

That's better than a mitigation not taking place at all.

> How multiple re-directs are operationally useful is yet to be seen and 

How multiple re-directs are harmful, given the fact that everybody knows 
it will take a bit more time, has yet to be seen and discussed in the 
WG.

MSSP can't handle the DOTS requests due to capacity constraints, and 
redirects to MSSP B.  MSSP B is undergoing a maintenance window, and so 
redirects to MSSP.  For example.

Again, shackling DOTS users based upon arbitrary decisions of what 
constitutes allowable delay - and the delays in question are minuscule, 
in actual chronological time - is arrogating to ourselves operational 
decisions which the users ought to be able to make for themselves.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 16:24:19 +0000

> Sent: Wednesday, March 23, 2016 7:55 PM
> To: dots
> How multiple re-directs are harmful, given the fact that everybody knows it
> will take a bit more time, has yet to be seen and discussed in the WG.
> 

MSSP before re-directing to MSPP B can check if MSPP B can handle the attack or not and then re-direct (Just like CDN avoids multiple re-directions,  upstream CDN contacts multiple downstream CDN's to figure out the best one to serve the content).

> constitutes allowable delay - and the delays in question are minuscule, in
> actual chronological time - is arrogating to ourselves operational decisions
> which the users ought to be able to make for themselves.

The problem is not just delay but also packet loss. The link is congested during the attack and responses from the DOTS server could get lost.

-Tiru

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 24 Mar 2016 11:06:13 +0700

On 23 Mar 2016, at 23:24, Tirumaleswar Reddy (tireddy) wrote:

> can check if MSPP B can handle the attack or not and then re-direct

That's undesirable for multiple reasons, not the least of which is extra 
unnecessary delay, as well as unknown (prior to signaling attempt) 
communications path state between MSSP and MSSP B.

Better for it to be direct between requesting network and each MSSP.

> The problem is not just delay but also packet loss. The link is 
> congested during the attack and responses from the DOTS server could 
> get lost.

That's potentially true, especially if this is a stateful-transport 
situation, and if OOB isn't used (we should always strongly recommend 
OOB, although it won't be the majority of deployments, sadly).  
Nevertheless, that's true of all communications in this type of 
scenario.

Retraction is potentially more helpful than mere rejection.