Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction

From: <[email-masked]>
Date: Wed, 14 Feb 2018 08:18:41 +0000

Hi all,

As agreed during the interim, there are some issues that need fixes in the data-channel spec. We would like to hear from the WG to know what to record in the document.

Issue description: Do we need to support explicit "direction" in filtering rules ("in"/"out")? That is, do we allow a DOTS client to create filters for both incoming and outgoing traffic?

Below a proposal for discussion:

-    The current default direction is aligned with the nature of DDoS attacks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed to be the destination. No ambiguity so far with such default behavior.

-    There is no clear use case for the support of outgoing filtering handling in the context of DOTS.

-    No text change is required to the draft.

Any objection?

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 15 Feb 2018 15:31:00 +0000

The filtering rule for outgoing traffic is required for the "Suppression of outbound DDoS traffic originating from a consumer broadband access network" use case discussed in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. In this use case, the CPE initially acts as a DOTS client but after the TCP connection is established, reverses its role and acts as DOTS server (see https://tools.ietf.org/html/rfc8071). The access network can then program the CPE using the DOTS data channel to block the DDoS attack traffic originated from the compromised devices in the
local customer network.

Cheers,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 14, 2018 1:49 PM
To: [email-masked]
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi all,

Any objection?

Cheers,

Med

---

From: <[email-masked]>
Date: Fri, 16 Feb 2018 07:53:40 +0000

Hi Tiru,

There will be an ambiguity in interpreting filters if and only if the same DOTS agents have to manipulate filters in both directions.

As you rightfully mentioned, the bb use case assumes the following:

   In order to achieve this capability, the telemetry analysis system
   utilized by the broadband access provider must have DOTS client
   functionality, and the end-customer CPE devices must have DOTS server
   functionality.

Which means that there is no ambiguity in that case with the current default direction: "the destination is the DOTS client domain".

No matter how roles were negotiated, but as far as each an agent acts as a client and its peer as a server, things are clear.

Of course we can always define an optional parameter for this, but it is preferable to have a case for it.

Cheers,

Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 15 février 2018 16:31
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: draft-ietf-dots-data-channel: Filter Direction

Cheers,
-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, February 14, 2018 1:49 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi all,

Any objection?

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 08:27:39 +0000

There is no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS server is initiating connection to the DOTS client in the access network. The DOTS client will convey the black-list filtering in the "out" direction to block the traffic originating from the DOTS server domain.
I don't understand what you mean by a "optional" parameter ?

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi Tiru,

Cheers,

Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 15 février 2018 16:31
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: draft-ietf-dots-data-channel: Filter Direction

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: <[email-masked]>
Date: Fri, 16 Feb 2018 08:48:40 +0000

Re-,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : vendredi 16 février 2018 09:28
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

There is no ambiguity in the roles. The CPE is acting as DOTS server but the DOTS server is initiating connection to the DOTS client in the access network.
[Med] Don't get the last part. The server (CPE) will receive a request from the network (client) to filter traffic exiting from that CPE.

The DOTS client will convey the black-list filtering in the "out" direction to block the traffic originating from the DOTS server domain.
[Med] Which corresponds to the "DOTS Server to DOTS Client" direction; that is the DOTS client domain (access network) is the destination. All is fine so far :)

I don't understand what you mean by a "optional" parameter ?
[Med] I meant adding a parameter to indicate explicitly the direction. It would be optional because we do already have a default direction.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 09:06:34 +0000

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

Re-,

Please see inline.

Cheers,
Med

[TR] I mean to use the call home feature discussed in https://tools.ietf.org/html/rfc8071, though the CPE is acting as a DOTS server it will initiate the connection (TLS or DTLS) to the DOTS client in the access network. The call home feature helps avoid various threats like the DOTS server in the CPE will not be subjected to DDoS attacks, and reachability is not problem even if the CPE is behind NAT.

[TR] The direction is "outgoing traffic" whereas for other use cases the direction is "incoming traffic".

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 09:57:29 -0000

I understand the concept of call home – which makes good sense to me and
rfc8071 will, if implemented, handle the data channel and “destination” is
still where the ‘controlled’ traffic is flowing to.

However, we also need call home in the signal channel.  I’m not sure how
this will be done – do we need a new CoAP Method (e.g. switch roles) – do we
need to define a different port (rfc8071 defines 4336) etc.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 16 February 2018 09:07
To: [email-masked]; [email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

Re-,

Please see inline. 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
Reddy
Envoyé : vendredi 16 février 2018 09:28
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

There is no ambiguity in the roles. The CPE is acting as DOTS server but the
DOTS server is initiating connection to the DOTS client in the access
network.

[Med] Don’t get the last part. The server (CPE) will receive a request from
the network (client) to filter traffic exiting from that CPE. 

[TR] I mean to use the call home feature discussed in
https://tools.ietf.org/html/rfc8071, though the CPE is acting as a DOTS
server it will initiate the connection (TLS or DTLS) to the DOTS client in
the access network. The call home feature helps avoid various threats like
the DOTS server in the CPE will not be subjected to DDoS attacks, and
reachability is not problem even if the CPE is behind NAT. 

The DOTS client will convey the black-list filtering in the “out” direction
to block the traffic originating from the DOTS server domain.

[Med] Which corresponds to the “DOTS Server to DOTS Client” direction; that
is the DOTS client domain (access network) is the destination. All is fine
so far :) 

[TR] The direction is “outgoing traffic” whereas for other use cases the
direction is “incoming traffic”. 

I don’t understand what you mean by a “optional” parameter ?

[Med] I meant adding a parameter to indicate explicitly the direction. It
would be optional because we do already have a default direction.

[TR] Okay.

-Tiru

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, February 16, 2018 1:24 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi Tiru, 

There will be an ambiguity in interpreting filters if and only if the same
DOTS agents have to manipulate filters in both directions. 

   functionality.

Which means that there is no ambiguity in that case with the current default
direction: “the destination is the DOTS client domain”. 

No matter how roles were negotiated, but as far as each an agent acts as a
client and its peer as a server, things are clear. 
 
Of course we can always define an optional parameter for this, but it is
preferable to have a case for it.  
 
Cheers,
Med

The filtering rule for outgoing traffic is required for the "Suppression of
outbound DDoS traffic originating from a consumer broadband access network"
use case discussed in
https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1. In
this use case, the CPE initially acts as a DOTS client but after the TCP
connection is established, reverses its role and acts as DOTS server (see
https://tools.ietf.org/html/rfc8071). The access network can then program
the CPE using the DOTS data channel to block the DDoS attack traffic
originated from the compromised devices in the 

local customer network. 

Cheers,

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, February 14, 2018 1:49 PM
To: [email-masked]
Subject: [Dots] draft-ietf-dots-data-channel: Filter Direction

Hi all, 

As agreed during the interim, there are some issues that need fixes in the
data-channel spec. We would like to hear from the WG to know what to record
in the document. 

Issue description: Do we need to support explicit “direction” in filtering
rules (“in”/“out”)? That is, do we allow a DOTS client to create filters for
both incoming and outgoing traffic? 

–    The current default direction is aligned with the nature of DDoS
attacks targeted by DOTS: i.e. incoming. The DOTS client domain is assumed
to be the destination. No ambiguity so far with such default behavior. 

–    There is no clear use case for the support of outgoing filtering
handling in the context of DOTS.

–    No text change is required to the draft.

Any objection? 

Cheers,

Med

---

From: <[email-masked]>
Date: Fri, 16 Feb 2018 10:08:59 +0000

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 16 février 2018 10:07
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: draft-ietf-dots-data-channel: Filter Direction

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, February 16, 2018 2:19 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

Re-,

Please see inline.

Cheers,
Med

[Med] OK.

[TR] The direction is "outgoing traffic" whereas for other use cases the direction is "incoming traffic".
[Med] Tiru, the direction in both cases is always the same: "DOTS Server to DOTS Client". Of course, from the perspective of the CPE (not the DOTS agent role), this will be "out" or "in" depending on the DOTS agent role on the CPE, but this is not important to determine the direction of the filters; only DOTS roles matter.

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 10:16:05 +0000

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, February 16, 2018 3:27 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filter Direction

I understand the concept of call home - which makes good sense to me and rfc8071 will, if implemented, handle the data channel and "destination" is still where the 'controlled' traffic is flowing to.

[TR] Yes.

However, we also need call home in the signal channel.  I'm not sure how this will be done - do we need a new CoAP Method (e.g. switch roles) - do we need to define a different port (rfc8071 defines 4336) etc.

[TR] For the discussed use case, the CPE needs to act as a DOTS server only for the data channel but not for the signal channel, I mean what is the use case for the call home in the signal channel ?.

-Tiru

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 09:07
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

Re-,

Please see inline.

Cheers,
Med

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 10:25:20 +0000

Please see inline [TR2]

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 16, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

Re-,

Please see inline.

Cheers,
Med

Re-,

Please see inline.

Cheers,
Med

[TR2] The device on which ACL gets enforced need not be co-located with the DOTS agent, the policy enforcement point (either CPE or DDoS mitigator) where the ACL is installed either sees an incoming attack or outgoing attack. The optional parameter should specify this direction. I don't see the value add the new parameter provides by just saying the attack traffic destination is from  the "DOTS server to DOTS client" or "DOTS client to DOTS server" (we don't have a valid use case for the latter value).

Cheers,
-Tiru

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: <[email-masked]>
Date: Fri, 16 Feb 2018 10:36:05 +0000

Tiru,

[TR2] The device on which ACL gets enforced need not be co-located with the DOTS agent, the policy enforcement point (either CPE or DDoS mitigator) where the ACL is installed either sees an incoming attack or outgoing attack. The optional parameter should specify this direction.

Please remember that we do have the following in the draft:

   How filtering rules instantiated on a DOTS server are translated into
   network configurations actions is out of scope.

When it comes to enforcing ACLs on devices, draft-ietf-netmod-acl does already support how to indicate ingress/egress attachment points. Translating DOTS filtering rules (including setting direction) into device/network specific ones t is under the responsibility of the server domain. This is out of scope.

[TR2] I don't see the value add the new parameter provides by just saying the attack traffic destination is from  the "DOTS server to DOTS client" or "DOTS client to DOTS server" (we don't have a valid use case for the latter value).

I don't see a value for it, either. This is exactly what I meant by "it is preferable to have a case for it". We are in full agreement :)

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : vendredi 16 février 2018 11:25
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: draft-ietf-dots-data-channel: Filter Direction

Please see inline [TR2]

Re-,

Please see inline.

Cheers,
Med

Re-,

Please see inline.

Cheers,
Med

Cheers,
-Tiru

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 10:57:40 +0000

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 16, 2018 4:06 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-dots-data-channel: Filter Direction

Tiru,

[TR3] Okay.

[TR3] Good, no need to add a new parameter :)

-Tiru

Cheers,
Med

Please see inline [TR2]

Re-,

Please see inline.

Cheers,
Med

Re-,

Please see inline.

Cheers,
Med

Cheers,
-Tiru

[TR] Okay.

-Tiru

-Tiru

Hi Tiru,

Cheers,

Med

Cheers,
-Tiru

Hi all,

Any objection?

Cheers,

Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 10:58:45 -0000

Hi there,

I concur that that there is not a need for a directional parameter.
“Source” is source, and “destination” is destination – having a parameter
that overrides this direction will only serve to confuse (well certainly
me!).

>From a DOTS agent that is acting as DOTS server, “destination” is what needs
protecting – even for "Suppression of outbound DDoS traffic originating from
a consumer broadband access network" use case.

Regards

Jon

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 16 February 2018 10:36
To: Konda, Tirumaleswar Reddy; [email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filter Direction

Tiru, 

[TR2] The device on which ACL gets enforced need not be co-located with the
DOTS agent, the policy enforcement point (either CPE or DDoS mitigator)
where the ACL is installed either sees an incoming attack or outgoing
attack. The optional parameter should specify this direction. 

When it comes to enforcing ACLs on devices, draft-ietf-netmod-acl does
already support how to indicate ingress/egress attachment points.
Translating DOTS filtering rules (including setting direction) into
device/network specific ones t is under the responsibility of the server
domain. This is out of scope.   

[TR2] I don’t see the value add the new parameter provides by just saying
the attack traffic destination is from  the “DOTS server to DOTS client” or
“DOTS client to DOTS server” (we don’t have a valid use case for the latter
value).

I don’t see a value for it, either. This is exactly what I meant by “it is
preferable to have a case for it”. We are in full agreement :) 

Cheers,

Med

Please see inline [TR2]

Re-,

Please see inline. 

Cheers,

Med

Re-,

Please see inline. 

Cheers,

Med

[Med] OK. 

 

[Med] Tiru, the direction in both cases is always the same: “DOTS Server to
DOTS Client”. Of course, from the perspective of the CPE (not the DOTS agent
role), this will be “out” or “in” depending on the DOTS agent role on the
CPE, but this is not important to determine the direction of the filters;
only DOTS roles matter.

[TR2] The device on which ACL gets enforced need not be co-located with the
DOTS agent, the policy enforcement point (either CPE or DDoS mitigator)
where the ACL is installed either sees an incoming attack or outgoing
attack. The optional parameter should specify this direction. I don’t see
the value add the new parameter provides by just saying the attack traffic
destination is from  the “DOTS server to DOTS client” or “DOTS client to
DOTS server” (we don’t have a valid use case for the latter value).

Cheers,

-Tiru

[TR] Okay.

-Tiru

-Tiru

Hi Tiru, 

   functionality.

 
 
Cheers,
Med

local customer network. 

Cheers,

-Tiru

Hi all, 

Any objection? 

Cheers,

Med