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

From: "Jon Shallow" <[email-masked]>
Date: Fri, 6 Apr 2018 14:27:59 +0100

Hi there,

There is no current way to request of a DOTS Server as to what is the set of
IP networks that a DOTS client can use either within a mitigation request or
to set up an ACL other than by “testing for ok or not ok” with lots of
different IP addresses.

There is a reasonable likelihood of the scope of valid IPs from the Server’s
perspective will change over time.  So, unless a DOTS client wants to
control a specific destination network, then my suggestion would be to leave
the ACE destination network empty and for the DOTS Server / DOTS mitigator
(how is out of scope) to fill it in at time of ACE instantiation.

Regards

Jon

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

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]] 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?

[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]>; [email-masked]
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4

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,

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.

[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.

“

[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.

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”,

[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.

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: Fri, 6 Apr 2018 15:19:02 +0000

I don't understand how the DOTS server/mitigation will fill it in at time of ACE instantiation, and why can't the DOTS client fill the destination network details ?

-Tiru

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

Hi there,

There is no current way to request of a DOTS Server as to what is the set of IP networks that a DOTS client can use either within a mitigation request or to set up an ACL other than by "testing for ok or not ok" with lots of different IP addresses.

There is a reasonable likelihood of the scope of valid IPs from the Server's perspective will change over time.  So, unless a DOTS client wants to control a specific destination network, then my suggestion would be to leave the ACE destination network empty and for the DOTS Server / DOTS mitigator (how is out of scope) to fill it in at time of ACE instantiation.

Regards

Jon

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

Please see inline [TR]

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[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

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,

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

..;

      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.

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",
[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.

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: "Jon Shallow" <[email-masked]>
Date: Fri, 6 Apr 2018 16:44:26 +0100

Hi Tiru,

The DOTS server is likely to have a scope of IP addresses that are valid for
the client to ask for protection for based on the cuid or cdid.

The DOTS client may have some knowledge of the scope IPs by some out of band
method, but programmatically cannot ask the server what they are. 

If a client specifies a destination network that is out of the valid scope
of IP addresses, then the ACE request will get rejected.  The client may
then have a challenge to work out what destination networks it is allowed to
use.

How does a client set up a blacklist for all the IPS within his allowed
scope if it does not know what the scope is?

If the client has not provided a destination network, then the DOTS server
can auto-fill in the missing information at the time of the ACE
instantiation – and this then handles if the scope of IP addresses change.

Regards

Jon

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

I don’t understand how the DOTS server/mitigation will fill it in at time of
ACE instantiation, and why can’t the DOTS client fill the destination
network details ?

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-Tiru

[email-masked] <mailto:[email-masked]> 

Hi Jon, 

Please see inline.

Cheers,

Med

Hi there,

• Conclusion

“Nevertheless, an

..;

“

~Jon

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 7 Apr 2018 05:48:13 +0000

Hi Jon,

DOTS clients (intelligent DDoS mitigation system, application server) will know the destination networks, what kind of DOTS clients will not know the destination networks they are allowed to use ?
DOTS clients could be behind client-domain DOTS gateway, DOTS server will have no way to validate the DOTS client identity sending the ACE request to determine the destination IP addresses in its scope, it will only know the destination IP addresses in the DOTS client domain scope.
Further, the implicit rule can be misused by compromised DOTS clients (e.g. black-list good traffic to the entire DOTS client domain) and it's a  troubleshooting nightmare to find the culprit device adversely impacting the entire network.

Cheers,
-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, April 6, 2018 9:14 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Tiru,

The DOTS server is likely to have a scope of IP addresses that are valid for the client to ask for protection for based on the cuid or cdid.

The DOTS client may have some knowledge of the scope IPs by some out of band method, but programmatically cannot ask the server what they are.

If a client specifies a destination network that is out of the valid scope of IP addresses, then the ACE request will get rejected.  The client may then have a challenge to work out what destination networks it is allowed to use.

How does a client set up a blacklist for all the IPS within his allowed scope if it does not know what the scope is?

If the client has not provided a destination network, then the DOTS server can auto-fill in the missing information at the time of the ACE instantiation - and this then handles if the scope of IP addresses change.

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-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.
"

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 9 Apr 2018 10:25:08 +0100

Hi Tiru,

If a DOTS client knows the full scope of the Networks that it is allowed to
use in a ACL or mitigate request, and the DOTS server limits any update from
that client to the scope of Networks (with any unexpected side effects that
may have), then there is no difference in my mind as to whether the DOTS
clients fills in the destination-network, or the DOTS server does so on the
DOTS client’s behalf before ACL instantiation if destination-network is not
defined.

For a client behind a client domain DOTS gateway, there may be non public IP
addresses that the (DMS) client is responsible for, but these should never
be sent out through the DOTS gateway (and should be rejected by the DOTS
server as out of scope).  There does have to be a common agreement between
DOTS client & DOTS server as to what Networks are in scope, but the DOTS
client currently cannot request this from the DOTS server and has to be
agreed out of band.

There is no reason as to why the DOTS server cannot maintain a valid scope
of Networks that the client domain DOTS gateway is allowed to request for
validity checking – unless I am missing something?

Troubleshooting has kept me in a job for more years than I care to remember,
anything to aid troubleshooting is what I am interested in and so totally
agree that rogue DOTS client’s capabilities need to be kept under control
with suitable logging to aid diagnosis is a major plus.  However in this
case, the implicit rule is no different to the DOTS client requesting the
full Networks scope in an ACL request.

Regards

Jon

From: Konda, Tirumaleswar Reddy [mailto: [email-masked]]

Sent: 07 April 2018 06:48
To: Jon Shallow; [email-masked]; [email-masked]
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Jon,

DOTS clients (intelligent DDoS mitigation system, application server) will
know the destination networks, what kind of DOTS clients will not know the
destination networks they are allowed to use ?

DOTS clients could be behind client-domain DOTS gateway, DOTS server will
have no way to validate the DOTS client identity sending the ACE request to
determine the destination IP addresses in its scope, it will only know the
destination IP addresses in the DOTS client domain scope. 

Further, the implicit rule can be misused by compromised DOTS clients (e.g.
black-list good traffic to the entire DOTS client domain) and it’s a
troubleshooting nightmare to find the culprit device adversely impacting the
entire network.

Cheers,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-Tiru

Hi Jon, 

Please see inline.

Cheers,

Med

Hi there,

• Conclusion

“Nevertheless, an

..;

“

~Jon

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Apr 2018 10:32:12 +0000

Hi Jon,

Please see inline

From: Jon Shallow [mailto:[email-masked]]
Sent: Monday, April 9, 2018 2:55 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Tiru,

If a DOTS client knows the full scope of the Networks that it is allowed to use in a ACL or mitigate request, and the DOTS server limits any update from that client to the scope of Networks (with any unexpected side effects that may have), then there is no difference in my mind as to whether the DOTS clients fills in the destination-network, or the DOTS server does so on the DOTS client's behalf before ACL instantiation if destination-network is not defined.

[TR] The above model only works when the DOTS server and DOTS client are directly communicating with each other (In the above, the DOTS server knows the DOTS client identity to enforce the scope but will not the DOTS client identity in the presence of a client-domain DOTS gateway).

For a client behind a client domain DOTS gateway, there may be non public IP addresses that the (DMS) client is responsible for, but these should never be sent out through the DOTS gateway (and should be rejected by the DOTS server as out of scope).  There does have to be a common agreement between DOTS client & DOTS server as to what Networks are in scope, but the DOTS client currently cannot request this from the DOTS server and has to be agreed out of band.

[TR] I don't see a new problem, even when a DOTS client sends a mitigation request it needs to know if the targets conveyed in the mitigation request are in its scope or not.

There is no reason as to why the DOTS server cannot maintain a valid scope of Networks that the client domain DOTS gateway is allowed to request for validity checking - unless I am missing something?

[TR] You are partially right, the DOTS server does not know the valid scope of prefixes that a DOTS client behind client-domain DOTS gateway is allowed to request.

Troubleshooting has kept me in a job for more years than I care to remember, anything to aid troubleshooting is what I am interested in and so totally agree that rogue DOTS client's capabilities need to be kept under control with suitable logging to aid diagnosis is a major plus.  However in this case, the implicit rule is no different to the DOTS client requesting the full Networks scope in an ACL request.

[TR] If the client is not authorized to request the full network scope, it can detected by the client-domain DOTS gateway and rejects the filtering rule by comparing the destination-networks
        specified in the ACE.

-Tiru

Regards

Jon

From: Konda, Tirumaleswar Reddy [mailto: [email-masked]<mailto:[email-masked]>]
Sent: 07 April 2018 06:48
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,

Cheers,
-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-Tiru

Hi Jon,

Please see inline.

Cheers,
Med

Hi there,

* Conclusion

"Nevertheless, an

..;

      forward DDoS traffic.
"

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 9 Apr 2018 12:33:43 +0100

Hi Tiru,

See inline [Jon1]

Regards

Jon

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

Hi Jon,

Please see inline 

Hi Tiru,

[TR] The above model only works when the DOTS server and DOTS client are
directly communicating with each other (In the above, the DOTS server knows
the DOTS client identity to enforce the scope but will not the DOTS client
identity in the presence of a client-domain DOTS gateway). 

[Jon1] The last para of “10. Security Considerations” states

   DOTS servers MUST verify that requesting DOTS clients are entitled to

   trigger actions on a given IP prefix.  That is, only actions on IP

   resources that belong to the DOTS client' domain MUST be authorized

   by a DOTS server.  The exact mechanism for the DOTS servers to

   validate that the target prefixes are within the scope of the DOTS

   client's domain is deployment-specific.

[Jon1] So it makes no difference if the DOTS client happens to be an agent
part of a client-domain DOTS gateway.  If the client-domain DOTS gateway is
hiding all the ‘behind’ clients and presenting as single client, there is no
issue.  However, if the ‘behind’ clients are presented as 2 or more ‘cuid’s
by the DOTS gateway, then either the scope is per ‘cuid’, or if ‘cdid’s are
being applied by the upstream server domain DOTS gateway then on a per
‘cdid’ basis if wanted.

[TR] I don’t see a new problem, even when a DOTS client sends a mitigation
request it needs to know if the targets conveyed in the mitigation request
are in its scope or not.

[Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so has
to know scope.  I agree that the DOTS client (or client domain DOTS gateway)
needs to know (today out of band) what is the scope of what is valid to
request.  The challenge comes when the DOTS server’s scope is reconfigured,
but not yet updated on the DOTS client.  

[TR] You are partially right, the DOTS server does not know the valid scope
of prefixes that a DOTS client behind client-domain DOTS gateway is allowed
to request.

[Jon1] Again, the last para of 10. stands here, and so the scope has to be
known by the DOTS server.

[TR] If the client is not authorized to request the full network scope, it
can detected by the client-domain DOTS gateway and rejects the filtering
rule by comparing the destination-networks 

        specified in the ACE.

[Jon1] Agreed, it is the responsibility of the client domain DOTS gateway to
only allow out valid networks that are valid within the DOTS server’s scope.

[Jon1] Should we support a way for the client domain DOTS gateway  (i.e.
DOTS client agent) to programmatically get the current valid network scope
from the DOTS server?

~jon1

-Tiru

Regards

Jon

Hi Jon,

Cheers,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-Tiru

[email-masked] <mailto:[email-masked]> 

Hi Jon, 

Please see inline.

Cheers,

Med

Hi there,

• Conclusion

“Nevertheless, an

..;

“

~Jon

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Apr 2018 11:44:19 +0000

Hi Jon,

Please see inline [TR2]

From: Jon Shallow [mailto:[email-masked]]
Sent: Monday, April 9, 2018 5:04 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Tiru,

See inline [Jon1]

Regards

Jon

Hi Jon,

Please see inline

Hi Tiru,

[Jon1] The last para of "10. Security Considerations" states

[Jon1] So it makes no difference if the DOTS client happens to be an agent part of a client-domain DOTS gateway.  If the client-domain DOTS gateway is hiding all the 'behind' clients and presenting as single client, there is no issue.  However, if the 'behind' clients are presented as 2 or more 'cuid's by the DOTS gateway, then either the scope is per 'cuid', or if 'cdid's are being applied by the upstream server domain DOTS gateway then on a per 'cdid' basis if wanted.

[Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so has to know scope.  I agree that the DOTS client (or client domain DOTS gateway) needs to know (today out of band) what is the scope of what is valid to request.  The challenge comes when the DOTS server's scope is reconfigured, but not yet updated on the DOTS client.

[TR2] The scope would be first updated on the DOTS client domain and then on the DOTS server (e.g. IP prefix re-numbering).

[Jon1] Again, the last para of 10. stands here, and so the scope has to be known by the DOTS server.

[TR] Yes, but it may not know the scope of a DOTS client behind a client-domain DOTS gateway.

[TR] If the client is not authorized to request the full network scope, it can detected by the client-domain DOTS gateway and rejects the filtering rule by comparing the destination-networks
        specified in the ACE.
[Jon1] Agreed, it is the responsibility of the client domain DOTS gateway to only allow out valid networks that are valid within the DOTS server's scope.

[Jon1] Should we support a way for the client domain DOTS gateway  (i.e. DOTS client agent) to programmatically get the current valid network scope from the DOTS server?

[TR2] It will not solve the above problem of detecting and rejecting a rouge (or misconfigured) DOTS client behind client domain DOTS gateway sending ACL without specifying destination-network.

-Tiru

~jon1

-Tiru

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-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.
"

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 9 Apr 2018 22:24:43 +0100

Hi Tiru,

See inline [Jon2]

Regards

Jon

Hi Tiru,

[TR2] The scope would be first updated on the DOTS client domain and then on
the DOTS server (e.g. IP prefix re-numbering). 

[Jon2] I was more thinking of a DOTS client that got missed off a list when
the DOTS server was updated.  Normally though, they should be kept in sync
but which one gets updated first is uncertain to me.

[TR] Yes, but it may not know the scope of a DOTS client behind a
client-domain DOTS gateway.

[Jon2] But it will know what the client-domain DOTS gateway is allowed to
pass through in terms of Destination Network.  The client-domain DOTS
gateway will separately need to know what Destination networks are allowed
to get out through the gateway.

        specified in the ACE.

[TR2] It will not solve the above problem of detecting and rejecting a rouge
(or misconfigured) DOTS client behind client domain DOTS gateway sending ACL
without specifying destination-network.

[Jon2] Hmm.  If the client-domain DOTS gateway is restricted in scope as to
what it is allowed to request, and a rogue client behind the gateway does
not specify a destination-network, then when the request passes through the
gateway the upstream DOTS server will only use the scope allowed for that
specific client-domain DOTS gateway.  Again, it is exactly the same as if
the rogue client was to specify the full set of allowed scope as a set of
destination networks in terms of damage capabilities.

-Tiru

~jon1

-Tiru

Regards

Jon

Hi Jon,

Cheers,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-Tiru

[email-masked] <mailto:[email-masked]> 

Hi Jon, 

Please see inline.

Cheers,

Med

Hi there,

• Conclusion

“Nevertheless, an

..;

“

~Jon

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 05:42:57 +0000

Please see inline [TR3]

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, April 10, 2018 2:55 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Tiru,

See inline [Jon2]

Regards

Jon

Hi Tiru,

[Jon2] I was more thinking of a DOTS client that got missed off a list when the DOTS server was updated.  Normally though, they should be kept in sync but which one gets updated first is uncertain to me.

[TR3] If the DOTS client missed update, it will have various other problems; any network policy based on destination network IP/prefix will fail. DOTS client should support mechanisms to receive the latest network configuration after missing critical updates because it was offline or its
          connectivity was lost.

[Jon2] But it will know what the client-domain DOTS gateway is allowed to pass through in terms of Destination Network.  The client-domain DOTS gateway will separately need to know what Destination networks are allowed to get out through the gateway.

[Jon2] Hmm.  If the client-domain DOTS gateway is restricted in scope as to what it is allowed to request, and a rogue client behind the gateway does not specify a destination-network, then when the request passes through the gateway the upstream DOTS server will only use the scope allowed for that specific client-domain DOTS gateway.  Again, it is exactly the same as if the rogue client was to specify the full set of allowed scope as a set of destination networks in terms of damage capabilities.

[TR3] No, the client-domain DOTS gateway can detect and reject the ACL because the rouge DOTS client has specified destination-network not under its scope.

-Tiru

~jon1

-Tiru

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-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.
"

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Apr 2018 10:07:17 +0100

Hi Tiru,

See inline [Jon3]

Regards

Jon

Hi Tiru,

[TR3] If the DOTS client missed update, it will have various other problems;
any network policy based on destination network IP/prefix will fail. DOTS
client should support mechanisms to receive the latest network configuration
after missing critical updates because it was offline or its 

          connectivity was lost.

[Jon3] So to me, we need to add in something to the data channel protocol so
that a DOTS client can request as to what is the network current scope it is
allowed to ask for ACL/Mitigation for.

        specified in the ACE.

[TR3] No, the client-domain DOTS gateway can detect and reject the ACL
because the rouge DOTS client has specified destination-network not under
its scope. 

[Jon3] You are missing my point.  Agreed that the client-domain DOTS gateway
must sanity check what is passed through.  However, there will be a set of
Networks that are allowed through the DOTS gateway which are within the
defined scope of what the DOTS server allows.  This “allowed through
networks” can legitimately be set by the DOTS client in destination-network,
or the DOTS server can fill in the same set of networks in the ACL
instantiation if destination-networks was empty and the potential side
effects damage caused will be the same.

~jon2

-Tiru

~jon1

-Tiru

Regards

Jon

Hi Jon,

Cheers,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-Tiru

[email-masked] <mailto:[email-masked]> 

Hi Jon, 

Please see inline.

Cheers,

Med

Hi there,

• Conclusion

“Nevertheless, an

..;

“

~Jon

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 10:13:23 +0000

Please see inline [TR4]

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, April 10, 2018 2:37 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4

Hi Tiru,

See inline [Jon3]

Regards

Jon

Hi Tiru,

[Jon3] So to me, we need to add in something to the data channel protocol so that a DOTS client can request as to what is the network current scope it is allowed to ask for ACL/Mitigation for.

[TR3] I don't think so, you may want to look into SIG-007 requirement, it says "A DOTS client may obtain the mitigation scope through direct provisioning or through implementation-specific methods of discovery."

[Jon3] You are missing my point.  Agreed that the client-domain DOTS gateway must sanity check what is passed through.  However, there will be a set of Networks that are allowed through the DOTS gateway which are within the defined scope of what the DOTS server allows.  This "allowed through networks" can legitimately be set by the DOTS client in destination-network, or the DOTS server can fill in the same set of networks in the ACL instantiation if destination-networks was empty and the potential side effects damage caused will be the same.

[TR] I understand, you seem to be focusing on only DDoS detectors and IDMS acting as DOTS clients . They will be authorized to enforce ACL for the entire DOTS client domain, but an application server acting as a DOTS client will only be authorized to enforce ACL for the IP addresses/prefixes used by the it and not for the entire DOTS client domain. These type of DOTS clients must fill the destination-network, so the client-domain DOTS gateway can detect and reject ACL requests populated with destination IP addresses/prefixes the application server does not use.

-Tiru

~jon2

-Tiru

~jon1

-Tiru

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-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.
"

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Apr 2018 11:32:57 +0100

Hi Tiru,

See inline [Jon4]

Regards

Jon

Hi Tiru,

          connectivity was lost.

[TR4] I don’t think so, you may want to look into SIG-007 requirement, it
says “A DOTS client may obtain the mitigation scope through direct
provisioning or through implementation-specific methods of discovery.”
 
[Jon4] That does not preclude us adding it into the DOTS data protocol YANG
model.

        specified in the ACE.

[TR4] I understand, you seem to be focusing on only DDoS detectors and IDMS
acting as DOTS clients . They will be authorized to enforce ACL for the
entire DOTS client domain, but an application server acting as a DOTS client
will only be authorized to enforce ACL for the IP addresses/prefixes used by
the it and not for the entire DOTS client domain. These type of DOTS clients
must fill the destination-network, so the client-domain DOTS gateway can
detect and reject ACL requests populated with destination IP
addresses/prefixes the application server does not use. 

[Jon4]  I agree that the client-domain DOTS gateway has to have a notion of
which client can request what – i.e. maintaining a scope of what the
individual client can ask for.  Not convinced that we clearly define that a
client-domain DOTS gateway must maintain a Destination scope though.  There
is no reason as to why a client-domain DOTS gateway cannot fill in an empty
destination-network with the specifics for the requesting client though
before passing it through upstream – but it does look tidier if the client
does specify the destination-network.

-Tiru

~jon2

-Tiru

~jon1

-Tiru

Regards

Jon

Hi Jon,

Cheers,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-Tiru

[email-masked] <mailto:[email-masked]> 

Hi Jon, 

Please see inline.

Cheers,

Med

Hi there,

• Conclusion

“Nevertheless, an

..;

“

~Jon

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 11:44:56 +0000

Please see inline [TR5]

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

Hi Tiru,

See inline [Jon4]

Regards

Jon

Hi Tiru,

[TR4] I don't think so, you may want to look into SIG-007 requirement, it says "A DOTS client may obtain the mitigation scope through direct provisioning or through implementation-specific methods of discovery."

[Jon4] That does not preclude us adding it into the DOTS data protocol YANG model.

[TR5] No, it clearly says configurating the mitigation scope on the DOTS client is outside the scope of DOTS protocols.

[TR4] I understand, you seem to be focusing on only DDoS detectors and IDMS acting as DOTS clients . They will be authorized to enforce ACL for the entire DOTS client domain, but an application server acting as a DOTS client will only be authorized to enforce ACL for the IP addresses/prefixes used by the it and not for the entire DOTS client domain. These type of DOTS clients must fill the destination-network, so the client-domain DOTS gateway can detect and reject ACL requests populated with destination IP addresses/prefixes the application server does not use.

[Jon4]  I agree that the client-domain DOTS gateway has to have a notion of which client can request what - i.e. maintaining a scope of what the individual client can ask for.  Not convinced that we clearly define that a client-domain DOTS gateway must maintain a Destination scope though.  There is no reason as to why a client-domain DOTS gateway cannot fill in an empty destination-network with the specifics for the requesting client though before passing it through upstream - but it does look tidier if the client does specify the destination-network.

[TR5] It significantly increases the work on the client-domain gateways, it will have to modify the response (to remove the destination-network from the ACE) when the client is using GET to retrieve the installed filtering rules and will  have to remember if the destination-network was updated by it or not. The client anyway knows its mitigation scope, and cannot not a mitigation request without specifying the mitigation scope (similar to destination-networks specified in ACE).

-Tiru

~jon2

-Tiru

~jon1

-Tiru

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi there,

Regards

Jon

Please see inline [TR]

Hi Tiru / Med

See inline [Jon]

Regards

Jon

-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.
"

Regards

Jon