Subject: [Dots] DOTS Requirements review (-06)

From: Flemming Andreasen <[email-masked]>
Date: Sun, 22 Oct 2017 15:17:08 -0400

Greetings

I have reviewed the latest version of the DOTS requirements draft 
(https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt). In 
general, I think the draft is in good shape with only a few edits 
required, so I hope we can move to WGLC soon. I have a few comments 
below (of which the NAT one is the only real substantial one). I have 
also submitted a pull request with a few nit fixes on GitHub:

Section 1.2
- The definition of "DOTS Signal" is slightly inconsistent with the 
respective "Client Signal" and "Server Signal" definitions.

SIG-005:
- Not clear that always requiring "number of packets" metrics is 
meaningful. Consider TCP-based attacks for example. Number of bytes may 
always be ok - above and beyond that it should probably be extensible 
and/or attack dependent.
- I don't think the requirements document should get into specifying 
timer values - expontial backoff with some maximum value seems about the 
right level of detail here.

SIG-009:
- To be clear, the conflicts only apply within a single administrative 
domain, right ? For example, if a client tells the same domain to 
alternately turn on/off mitigation for a given prefix, route flapping 
may occur. The same concern does not apply if a client tells two 
different administrative domains to respective turn mitigation on 
(domain 1) and off (domain 2). If so, can we clarify that (also in lieu 
of some of the multi-homing comments raised previously) ?

SIG-010:
- DOTS Client behind NAT. On one hand, it seems reasonable to have this 
requirement since clients for sure can be behind NATs, and with things 
like dynamic DNS, they can     certainly be reachable. However, if we do 
want to allow for this scenario, and in particular for the DOTS client 
to have a private IP-address (potentially behind multiple NATs), then we 
have more work to do because it won't do the DOTS server any good to get 
a mitigation request referring to that private IP-address (or prefix).

Thanks

-- Flemming

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 23 Oct 2017 12:17:33 +0100

Hi Flemming,

The way my mind works is to think of a practical situation and see if things fit.

As I read SIG-010, there could be a DOTS client with a management IP address that is RFC1918 - this client could be monitoring Netflow information and can request mitigation for the appropriate public IPs that are being monitored.  So SIG-010 is needed for this use case.

It is the responsibility of the DOTS server as to whether it accepts a mitigation request for a particular target ip (or domain etc.) or not.

If there is going to be a NAT border where public IPs are mapped into private IPs (and vice versa), I would then expect there to be a DOTS gateway between these 2 zones, and it is the responsibility of the DOTS gateway to do any target-ip mappings.

Regards

Jon

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: 22 October 2017 20:17
To: dots; [email-masked]
Subject: [Dots] DOTS Requirements review (-06)

Greetings

I have reviewed the latest version of the DOTS requirements draft (https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt). In general, I think the draft is in good shape with only a few edits required, so I hope we can move to WGLC soon. I have a few comments below (of which the NAT one is the only real substantial one). I have also submitted a pull request with a few nit fixes on GitHub:

Section 1.2
- The definition of "DOTS Signal" is slightly inconsistent with the respective "Client Signal" and "Server Signal" definitions.

SIG-005:
- Not clear that always requiring "number of packets" metrics is meaningful. Consider TCP-based attacks for example. Number of bytes may always be ok - above and beyond that it should probably be extensible and/or attack dependent.
- I don't think the requirements document should get into specifying timer values - expontial backoff with some maximum value seems about the right level of detail here.

SIG-009:
- To be clear, the conflicts only apply within a single administrative domain, right ? For example, if a client tells the same domain to alternately turn on/off mitigation for a given prefix, route flapping may occur. The same concern does not apply if a client tells two different administrative domains to respective turn mitigation on (domain 1) and off (domain 2). If so, can we clarify that (also in lieu of some of the multi-homing comments raised previously) ?

SIG-010:
- DOTS Client behind NAT. On one hand, it seems reasonable to have this requirement since clients for sure can be behind NATs, and with things like dynamic DNS, they can     certainly be reachable. However, if we do want to allow for this scenario, and in particular for the DOTS client to have a private IP-address (potentially behind multiple NATs), then we have more work to do because it won't do the DOTS server any good to get a mitigation request referring to that private IP-address (or prefix).

Thanks

-- Flemming

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Oct 2017 11:29:06 -0400

> As I read SIG-010, there could be a DOTS client with a management IP address that is RFC1918 - this client could be monitoring Netflow information and can request mitigation for the appropriate pub…
Agreed.

What about when the attack target is also using a private IP address ?
> It is the responsibility of the DOTS server as to whether it accepts a mitigation request for a particular target ip (or domain etc.) or not.
Fair enough, but if we want the protocol to work for attack targets that 
have private IP-addresses, then we need to say more about how that is 
going to work.
> If there is going to be a NAT border where public IPs are mapped into private IPs (and vice versa), I would then expect there to be a DOTS gateway between these 2 zones, and it is the responsibilit…
Agree that's an option, but it's not the only.

Cheers

-- Flemming

> .