Subject: Re: [Dots] Comments on draft-ietf-dots-architecture-02

From: "Mortensen, Andrew" <[email-masked]>
Date: Thu, 1 Jun 2017 16:58:36 +0000

Thanks for the comments, Russ. My responses are inline.

andrew

On May 29, 2017, at 9:14 PM, Russ White <[email-masked]<mailto:[email-masked]>> wrote:

==
I would again question the focus on UDP, essentially disallowing QUIC. Allowing multiple transports might be useful.

I believe all the UDP usages are examples or in reference to the requirements. I think in addressing the transport requirements we should be able to make a very small adjustment here and be done with it.

==
First of all, a DOTS agent belongs to an domain, and that domain has an identity which can be authenticated and authorized.

Probably would be better as something like --

First, a DOTS agent belongs to a domain; and the domain to which the DOTS server belongs has an identity which can…

Updated.

==
[[EDITOR’S NOTE: we request working group feedback and discussion of operational considerations relating to coordinating multiple provider responses to a mitigation request.]]

One problem worth mentioning here would be one "customer" sending different redirects to multiple "providers" that result in a permanent routing loop. There does not seem to be any way to solve this within the DOTS framework that I can see, but it might be worth pointing out that this is a potential problem.

We’ve been tracking this issue on GitHub here:

<https://github.com/dotswg/dots-architecture/issues/6>

It sounds to me like you’re advocating for saying “Here be dragons, woe to you who ignore my warning” and leaving it at that, yes?

Another problem here is that of prioritizing various requests; there might want to be some mention here of how this is an issue that is not resolved in the protocol specification, but is rather expected to be solved in implementations. There may want to be a draft on this topic later on to discuss various strategies, and experience with them in actual deployments, but for this draft it just seems worth mentioning and leaving it at that.

This seems like a good approach to me.

---

From: "Russ White" <[email-masked]>
Date: Fri, 2 Jun 2017 15:20:37 -0400

> I believe all the UDP usages are examples or in reference to the requirements. I
> think in addressing the transport requirements we should be able to make a very
> small adjustment here and be done with it.

Okay -- that's fine... 

> 	[[EDITOR’S NOTE: we request working group feedback and discussion of
> operational considerations relating to coordinating multiple provider responses
> to a mitigation request.]]
> 
> 	One problem worth mentioning here would be one "customer"
> sending different redirects to multiple "providers" that result in a permanent
> routing loop. There does not seem to be any way to solve this within the DOTS
> framework that I can see, but it might be worth pointing out that this is a
> potential problem.

> It sounds to me like you’re advocating for saying “Here be dragons, woe to you
> who ignore my warning” and leaving it at that, yes?

I don't see another solution at this point within the protocol itself... There may be ways to detect this sort of condition, but I don't think they should be part of the base spec, but left to future work and consideration if the problem comes up enough in the field to warrant the work and complexity. It might this isn't a problem that ever really crops up...  
 
😊 /r

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Mon, 5 Jun 2017 19:04:48 +0000

On Jun 2, 2017, at 3:20 PM, Russ White <[email-masked]<mailto:[email-masked]>> wrote:

...

I don't see another solution at this point within the protocol itself... There may be ways to detect this sort of condition, but I don't think they should be part of the base spec, but left to future work and consideration if the problem comes up enough in the field to warrant the work and complexity. It might this isn't a problem that ever really crops up…

I’ve added some text I’m hoping will cover this adequately. You can see the updated draft here:

<https://raw.githubusercontent.com/amortensen/dots-architecture/master/draft-ietf-dots-architecture.txt>

andrew

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Mon, 5 Jun 2017 19:06:44 +0000

On Jun 5, 2017, at 3:04 PM, Andrew Mortensen <[email-masked]<mailto:[email-masked]>> wrote:

...

Whoops, meant to paste added paragraphs, too:

Deploying a multi-homed client requires extra care and planning, as the DOTS
servers with which the multi-homed client communicates may not be affiliated.
Should the multi-homed client simultaneously request for mitigation from all
servers with which it has established signal channels, the client may
unintentionally inflict additional network disruption on the resources it
intends to protect. In one of the worst cases, a multi-homed DOTS client could
cause a permanent routing loop of traffic destined for the client's protected
protected services, as the uncoordinated DOTS servers' mitigators all try to
divert that traffic to their own scrubbing centers.

The DOTS protocol itself provides no fool-proof method to prevent such
self-inflicted harms as a result deploying multi-homed DOTS clients. If
DOTS client implementations nevertheless include support for multi-homing, they
are expected to be aware of the risks, and consequently to include measures
aimed at reducing the likelihood of negative outcomes. Simple measures might
include:

* Requesting mitigation serially, ensuring only one mitigation request for
    a given address space is active at any given time;

* Dividing the protected resources among the DOTS servers, such that no two
    mitigators will be attempting to divert and scrub the same traffic;

* Using multi-homing for redundancy only. In this case, the DOTS servers would
    be affiliated, and through shared communications ensure that the redundant
    mitigation requests do not result in overlapping traffic diversion
    announcements.

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 6 Jun 2017 04:49:38 +0000

Please see inline [TR]

From: Dots [mailto:[email-masked]] On Behalf Of Mortensen, Andrew
Sent: Tuesday, June 6, 2017 12:37 AM
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dots] Comments on draft-ietf-dots-architecture-02

...

[TR] If the DOTS server receives a mitigation request with target prefixes and target IP addresses that it does not own then it can reject the mitigation request and avoid the permanent looping problem (see https://tools.ietf.org/html/rfc3704).

[TR] I did not get the above line, Multi-homing could be provided by a single service provider or multiple service providers (or referred to as provisioning domains in https://tools.ietf.org/html/rfc7556).

-Tiru

andrew

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Tue, 6 Jun 2017 18:00:53 +0000

Thanks Tiru. My responses are inline.

On Jun 6, 2017, at 12:49 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

Please see inline [TR]

From: Dots [mailto:[email-masked]] On Behalf Of Mortensen, Andrew
Sent: Tuesday, June 6, 2017 12:37 AM
To: Russ White <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Comments on draft-ietf-dots-architecture-02

...
[TR] If the DOTS server receives a mitigation request with target prefixes and target IP addresses that it does not own then it can reject the mitigation request and avoid the permanent looping problem (seehttps://tools.ietf.org/html/rfc3704).

Right. Do you not see this falling under the “dividing the protected resources among the DOTS servers” below?

...

The point I was trying to make was that the multi-homing case is less risky if the client is multi-homed to a set of coordinated/federated DOTS servers. Redundancy is an example of this, but a limiting example. I’ll revise.

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 7 Jun 2017 05:18:30 +0000

From: Mortensen, Andrew [mailto:[email-masked]]
Sent: Tuesday, June 6, 2017 11:31 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Russ White <[email-masked]>; [email-masked]
Subject: Re: [Dots] Comments on draft-ietf-dots-architecture-02

Please see inline [TR]

...

[TR] No, it’s not load-balancing; the DOTS client among the DOTS servers available has to select a DOTS server whose network has assigned the prefixes from which target prefixes and target IP addresses are derived.

...

[TR] Thanks.

-Tiru

andrew

---

From: <[email-masked]>
Date: Wed, 7 Jun 2017 12:21:46 +0000

Hi Tiru, all,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : mercredi 7 juin 2017 07:19
À : Mortensen, Andrew
Cc : [email-masked]; Russ White
Objet : Re: [Dots] Comments on draft-ietf-dots-architecture-02

From: Mortensen, Andrew [mailto:[email-masked]]
Sent: Tuesday, June 6, 2017 11:31 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>
Cc: Russ White <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Comments on draft-ietf-dots-architecture-02

Please see inline [TR]

...

[TR] No, it’s not load-balancing; the DOTS client among the DOTS servers available has to select a DOTS server whose network has assigned the prefixes from which target prefixes and target IP addresses are derived.
[Med] I agree with Tiru. Generally speaking, there is a need to have a discussion in the draft about DOTS selection when multi-homing. Other considerations should be taken into account, e.g., see this text proposal I shared with Andrew in my review:

“Multi-homed DOTS clients may be provided with multiple DOTS servers. Each DOTS server learned must be associated with the network interface on which it was learned. A multi-homed DOTS client must contact the appropriate DOTS server that is associated with an upstream network from which a DDoS attack is observed.”

...

[TR] Thanks.

-Tiru

andrew

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Wed, 7 Jun 2017 15:37:15 +0000

Thanks, response inline below.

On Jun 7, 2017, at 1:18 AM, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

I don’t think we’re disagreeing here. By “dividing the protected resources” I didn’t mean to suggest load balancing, but splitting what would be protected (e.g., unique prefixes) among the various DOTS servers, so that no two DOTS servers are being asked to mitigate traffic for the same resources.

andrew