Subject: [Dots] IETF 101 Presentation Data Channel Issue #4

From: "Jon Shallow" <[email-masked]>
Date: Mon, 26 Mar 2018 13:22:38 +0100

Hi there,

As per Med's presentation to the IETF 101

Issue #4: Per-Domain or Per-client Filters?

. Conclusion

- Filters that are activated only during mitigation time are on a per-client
basis

   . Filters are per-domain when are immediately applied

"Filters are per-domain when are immediately applied" is what I have an
challenge with.

If we have a compromised or rogue DOTS client, the simple use of something
like curl, along with the client certificates etc. can be used to generate
any ACL with activation-type := 'immediate' which is then immediately
applied for all traffic within the domain as per the above.

So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc.
can easily cause all of the other clients / devices within the domain to be
taken off air.  Putting the intelligence into the DOTS server to not allow
this to happen could be a challenge.

[The signal channel is much harder to compromise and affect traffic flows to
other areas within the domain]

I believe that an ACL instantiated by a DOTS client (immediate or
when-mitigating) should only apply to the DOTS client's traffic which means
that the destination-network has to be a part of the ACL, whether implicitly
added by the DOTS server, or by the DOTS client and suitably validated.

There is nothing to stop the DOTS server or DOTS mitigator merging common
ACLs to reduce the number of ACLs within the mitigation device.

As a side note "mitigation-time" is perhaps a bad name as it implies a time
period - something like "when-mitigating" to me is clearer.

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 27 Mar 2018 07:39:05 +0000

Hi Jon,

Thank you for the comments.

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : lundi 26 mars 2018 14:23
À : [email-masked]
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4

Hi there,

* Conclusion
- Filters that are activated only during mitigation time are on a per-client basis
   * Filters are per-domain when are immediately applied

"Filters are per-domain when are immediately applied" is what I have an challenge with.

If we have a compromised or rogue DOTS client, the simple use of something like curl, along with the client certificates etc. can be used to generate any ACL with activation-type := 'immediate' which is then immediately applied for all traffic within the domain as per the above.

[Med] Yes. FWIW, this attack is called out in the security considerations section:

"Nevertheless, an
   attacker who can access a DOTS client is technically capable of
   launching various attacks, such as:

..;

   o  Set invalid ACL entries, which may prevent legitimate traffic from

      being forwarded.  Likewise, invalid ACL entries may lead to

      forward DDoS traffic.
"

So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc. can easily cause all of the other clients / devices within the domain to be taken off air.  Putting the intelligence into the DOTS server to not allow this to happen could be a challenge.
[The signal channel is much harder to compromise and affect traffic flows to other areas within the domain]

I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client's traffic which means that the destination-network has to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

[Med] Putting aside that I don't parse "DOTS client's traffic", I interpret your answer as a support to this question raised for issue #4:
-    "Should we mandate destination-network to be present for immediately enforced filters?"

There is nothing to stop the DOTS server or DOTS mitigator merging common ACLs to reduce the number of ACLs within the mitigation device.

As a side note "mitigation-time" is perhaps a bad name as it implies a time period - something like "when-mitigating" to me is clearer.
[Med] Fixed in my local copy. Thank you.

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 27 Mar 2018 08:47:08 +0000

I also support to mandate destination-network for immediately enforced filtering rules.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <[email-masked]>; [email-masked]
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Jon,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : lundi 26 mars 2018 14:23
À : [email-masked]<mailto:[email-masked]>
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4

Hi there,

* Conclusion

"Nevertheless, an

..;

      forward DDoS traffic.
"

     *   "Should we mandate destination-network to be present for immediately enforced filters?"

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 27 Mar 2018 11:37:18 +0100

Hi Tiru / Med

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 27 March 2018 09:47
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4

I also support to mandate destination-network for immediately enforced
filtering rules.

[Jon] This can be enforced / inserted by the DOTS Server for all the
destination networks of the domain that the DOTS client ‘belongs’ to.  That
said, it would be good to always have the destination network in an ACL as
it can be validated and cross-checked whenever the legitimate set of domain
protected IPs are updated.

[Jon] However, what happens to the Destination network in the case of a call
home DOTS client that becomes a quasi DOTS server and the Destination
networks are somewhere out on the Internet?

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <[email-masked]>; [email-masked]
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Jon, 

Please see inline.

Cheers,

Med

Hi there,

As per Med’s presentation to the IETF 101

• Conclusion

– Filters that are activated only during mitigation time are on a per-client
basis

   • Filters are per-domain when are immediately applied

“Filters are per-domain when are immediately applied” is what I have an
challenge with.

If we have a compromised or rogue DOTS client, the simple use of something
like curl, along with the client certificates etc. can be used to generate
any ACL with activation-type := ‘immediate’ which is then immediately
applied for all traffic within the domain as per the above.

[Med] Yes. FWIW, this attack is called out in the security considerations
section: 

“Nevertheless, an

..;

“

[Jon] Agreed that the attack is covered off in the Security section, but we
should be limiting the possibility / scope of the attack vector by enforcing
some rules as to what is / is not allowed.  Allowing a DOTS client to be
able to affect all the traffic within the domain is a huge risk to me and
should not be allowed.

I believe that an ACL instantiated by a DOTS client (immediate or
when-mitigating) should only apply to the DOTS client’s traffic which means
that the destination-network has to be a part of the ACL, whether implicitly
added by the DOTS server, or by the DOTS client and suitably validated.

[Med] Putting aside that I don’t parse “DOTS client’s traffic”,

[Jon] I was referring to all the traffic flows that a DOTS client can
legitimately request control of to the DOTS server that are within the scope
of what the DOTS client is protecting (which may or may not be the DOTS
client’s IP address).

I interpret your answer as a support to this question raised for issue #4:

*	“Should we mandate destination-network to be present for immediately
enforced filters?”

[Jon] See response to Tiru’s Agreement above.

~Jon

As a side note “mitigation-time” is perhaps a bad name as it implies a time
period – something like “when-mitigating” to me is clearer.

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 27 Mar 2018 12:48:31 +0000

Please see inline [TR]

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Tiru / Med

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 09:47
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4

I also support to mandate destination-network for immediately enforced filtering rules.
[Jon] This can be enforced / inserted by the DOTS Server for all the destination networks of the domain that the DOTS client 'belongs' to.  That said, it would be good to always have the destination network in an ACL as it can be validated and cross-checked whenever the legitimate set of domain protected IPs are updated.
[Jon] However, what happens to the Destination network in the case of a call home DOTS client that becomes a quasi DOTS server and the Destination networks are somewhere out on the Internet?

[TR] DDOS is a targeted attack, so the DOTS client can specify the destination network targeted by devices in the DOTS server domain and the DOTS server can validate if the destination network is indeed targeted by its devices.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Jon,

Please see inline.

Cheers,
Med

Hi there,

* Conclusion

"Nevertheless, an

..;

      forward DDoS traffic.
"
[Jon] Agreed that the attack is covered off in the Security section, but we should be limiting the possibility / scope of the attack vector by enforcing some rules as to what is / is not allowed.  Allowing a DOTS client to be able to affect all the traffic within the domain is a huge risk to me and should not be allowed.

[Med] Putting aside that I don't parse "DOTS client's traffic",
[Jon] I was referring to all the traffic flows that a DOTS client can legitimately request control of to the DOTS server that are within the scope of what the DOTS client is protecting (which may or may not be the DOTS client's IP address).
I interpret your answer as a support to this question raised for issue #4:

     *   "Should we mandate destination-network to be present for immediately enforced filters?"
[Jon] See response to Tiru's Agreement above.
~Jon
There is nothing to stop the DOTS server or DOTS mitigator merging common ACLs to reduce the number of ACLs within the mitigation device.

Regards

Jon