Subject: [Dots] Signal / Data / Alias / Filter Implementation

From: "Jon Shallow" <[email-masked]>
Date: Wed, 2 Aug 2017 11:13:26 +0100

Hi There,

I am trying to get my mind around how to implement this and have some
questions / statements.

Signal Channel

The Signal channel looks very like Destination RTBH with some extras
(protocols / port) as everything is target-* based.  There is no concept of
source-ip, source-port (to handle reflection attacks) etc. or dealing with
fragmented packet, icmp types and rate-limiting.

The DOTS client may have the smarts to work out what are the problematic
source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that
will sensibly control the DDoS Attack.

It is possible to use a previously defined alias over the Data Channel as an
alternative for a mitigation request, but this too has source-* etc.
limitations.

I have not found a way of using a Filter defined over the Data Channel as a
signal

Sending a signal will cause all traffic to stop (or rate-limit possibly if
it also happens to match a filter) to the target IP on the ports in question
-  DDoS attack is now effective unless the DOTS server elects (via DNS or
BGP swing) to scrub that particular traffic (by controlling rates, Source
IPs / Source Ports etc.).

Data Channel

Can be used to set up aliases for later use.  These again however appear to
be target-* based, with no source-*, icmp type or fragmentation
capabilities.

Can set up a Filter, which does include both source and destination IPs, but
appears that it is acted on when pushed over the data channel, and cannot be
send as a signal - appears to be in place more for black/white listing IPs
than as a signal for mitigation, but does include rate-limiting

Questions

How do we handle Source-* information in a mitigation signal request?

How do we handle specific ICMP types  in a mitigation signal request?

How do we handle fragmentation  in a mitigation signal request?

Regards

Jon

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 02 Aug 2017 17:46:16 +0700

> will sensibly control the DDoS Attack.

Whatever orchestration system is getting input from the receiving DOTS 
server, actually.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 2 Aug 2017 16:24:56 +0100

I guess I am confused by your response.  Yes, the DOTS Server may be able to
work out the source-* information before passing it to the DOTS Mitigator,
but may need some hints from the DOTS client as to what to do.  I was not
expecting the DOTS Server to be feeding back information to the DOTS client
for the DOTS client to mitigate.

I (probably badly) was trying to describe a DOTS Client that had some
intelligence and could feed hints up to the DOTS Server.

In draft-ietf-dots-use-cases-07 
3.1.6.  End-customer operating a CPE network infrastructure device with
        an integrated DOTS client
The CPE device with integrated DOTS Client may be able to work out which
source-* and destination-* is needed to mitigate the attack (which could be
internet pipe flooding etc.) but has no mechanism to signal any source-*
information upstream to the DOTS server.

Hence 3  questions as to how can this source-* information be handled with
the current draft-ietf-dots-signal-channel ?

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Roland Dobbins
Sent: 02 August 2017 11:46
To: Jon Shallow
Cc: [email-masked]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

On 2 Aug 2017, at 17:13, Jon Shallow wrote:

> source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are 
> that will sensibly control the DDoS Attack.

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

---

From: "Dobbins, Roland" <[email-masked]>
Date: Wed, 2 Aug 2017 18:27:47 +0000

On Aug 2, 2017, at 22:25, Jon Shallow <[email-masked]<mailto:[email-masked]>> wrote:

3.1.6 from idraft-ietf-dots-use-cases-07 in full:

   Similar to the above use-case featuring applications or services with
   built-in DDoS attack detection/classification and DOTS client
   capabilities, in this scenario, an end-customer network
   infrastructure CPE device such as a router, layer-3 switch, firewall,
   or load-balance incorporates both the functionality required to
   detect and classify incoming DDoS attacks as well as DOTS client
   functionality.

   The subsequent DOTS communications dialogue and resultant DDoS
   mitigation initiation and termination activities take place in the
   same manner as the use-cases described above.

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

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 3 Aug 2017 14:21:01 +0900

Hi Jon,

I'm implementing the DOTS protocol based on current specifications.
The DOTS protocol can handle source-* information in a mitigation signal request.
For example, the DOTS server can enable BGP Flowspec from 5-tuple information derived from mitigation request message from DOTS client, that is actually we are planning to add to our software.
Destination information is used to validate whether the mitigation-scope is really the property of the DOTS client's organization or not.
So, if the request is only including source-* information, how to validate the request is another problem because it can cause unintended side effect to other customers/services (but could be implementation specific)

* How do we handle specific ICMP types  in a mitigation signal request?

Tiru wrote:
 > Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8).
 > I will extend the ACL YANG model in the next revision.

And the latest version of draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,)
I think we should update the draft.

* How do we handle fragmentation in a mitigation signal request?
fragmentation can be represented as port=0. Is this a sufficient representation?

thanks,
Kaname

On 2017/08/03 3:27, Dobbins, Roland wrote:
>
> On Aug 2, 2017, at 22:25, Jon Shallow <[email-masked] <mailto:[email-masked]>> wrote:
>
> Roland Dobbins <[email-masked] <mailto:[email-masked]>>
>
>

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 3 Aug 2017 08:56:57 +0100

Hi Kaname,

So as I read this, you are either extending the ietf-dot-signal definition to include source-* (and icmp, fragmentation and possibly rate-limiting) information or you are using Filters over the data channel (which is what Tiru is referring to).  If it is an extension to ietf-dot-signal, then this needs to be formalised for interoperability between different suppliers.  Similarly, ietf-dots-data-channel-identifier needs to be extended – but I do think the naming (e.g. target-ip instead of just ip) needs to be consistent between ietf-dot-signal and ietf-dots-data-channel-identifier.  “5.3.1” of draft-ietf-dots-signal-channel would also need to reflect the ietf-dot-signal change. “6.” and “10.1.2” of draft-ietf-dots-signal-channel would also need CBOR to be updated with source-* etc. definitions.

I am of the firm opinion that destination-ip is REQUIRED and MUST be within the mitigation scope of the DOTS Client to prevent taking out someone else’s IP.  This is true for ietf-dot-signal, ietf-dots-data-channel-identifier and ietf-dots-access-control-list.

I do not think fragmentation represented as port=0 is sufficient (and is not necessarily intuitive – it could be read as just take out the subsequent packets of a fragmented sequence if the layer 4 header is not there and hence no port). I think it should have its own ietf-dot-signal definition.

It is unclear to me the usage of alias in the ietf-dot-signal – is it the DOTS client uses just  the alias when requesting mitigation, or if extra parameters are provided (e.g. alias plus target-port-range) are the extra parameters a replacement or in addition to what is in the ietf-dots-data-channel-identifier or are the extra parameters ignored altogether?

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of kaname nishizuka
Sent: 03 August 2017 06:21
To: Dobbins, Roland; Jon Shallow
Cc: [email-masked]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Jon,

thanks,
Kaname

On Aug 2, 2017, at 22:25, Jon Shallow <[email-masked]> wrote:

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 3 Aug 2017 07:58:09 +0000

The source IP addresses and source ports used by the DDoS attacker could change, the type of attack itself could evolve or change from one attack type to another.
It was discussed in the WG that this kind of information are only hints and not mandatory to be conveyed by the DOTS client in the mitigation request.  https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses conveying the mitigation scope and not the source or type of the attack. However, DOTS signal channel draft allows vendor specific parameters and reserved key values in the range of 32768 to 65536 for vendor specific parameters, these hints can be conveyed as vendor-specific parameters to the DOTS server.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Wednesday, August 2, 2017 3:43 PM
To: [email-masked]
Subject: [Dots] Signal / Data / Alias / Filter Implementation

Hi There,

I am trying to get my mind around how to implement this and have some questions / statements.

Signal Channel

The Signal channel looks very like Destination RTBH with some extras (protocols / port) as everything is target-* based.  There is no concept of source-ip, source-port (to handle reflection attacks) etc. or dealing with fragmented packet, icmp types and rate-limiting.

The DOTS client may have the smarts to work out what are the problematic source-* etc. values (e.g. can generate smart BGP FlowSpec rules) are that will sensibly control the DDoS Attack.

It is possible to use a previously defined alias over the Data Channel as an alternative for a mitigation request, but this too has source-* etc. limitations.
I have not found a way of using a Filter defined over the Data Channel as a signal

Sending a signal will cause all traffic to stop (or rate-limit possibly if it also happens to match a filter) to the target IP on the ports in question -  DDoS attack is now effective unless the DOTS server elects (via DNS or BGP swing) to scrub that particular traffic (by controlling rates, Source IPs / Source Ports etc.).

Data Channel

Can be used to set up aliases for later use.  These again however appear to be target-* based, with no source-*, icmp type or fragmentation capabilities.

Can set up a Filter, which does include both source and destination IPs, but appears that it is acted on when pushed over the data channel, and cannot be send as a signal - appears to be in place more for black/white listing IPs than as a signal for mitigation, but does include rate-limiting

Questions

Regards

Jon

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 03 Aug 2017 15:04:32 +0700

On 3 Aug 2017, at 14:56, Jon Shallow wrote:

> I am of the firm opinion that destination-ip is REQUIRED

The intent of DOTS is NOT to re-create flowspec.

It's to signal the need for DDoS mitigation.

'Taking out someone else's IP' is not a concern of DOTS itself; this has 
to do with the provisioning of the DOTS clients, servers, and associated 
detection/classification/traceback/mitigation systems.

Getting into layer-4 traffic descriptors, including things like 
non-initial fragments, is re-creating flowspec and IPFIX.  We don't 
intend to do that.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 03 Aug 2017 15:04:59 +0700

On 3 Aug 2017, at 14:58, Konda, Tirumaleswar Reddy wrote:

> It was discussed in the WG that this kind of information are only 
> hints and not mandatory to be conveyed by the DOTS client in the 
> mitigation request.

Correct.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 3 Aug 2017 08:06:17 +0000

draft-ietf-dots-data-channel-02 extends the base ACL model defined in draft-ietf-netmod-acl-model to support filtering based on fragments. Filtering rules based on ICMP type and code is supported in latest revision of draft-ietf-netmod-acl-model.
I don’t see a need to update the DOTS data channel draft.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of kaname nishizuka
Sent: Thursday, August 3, 2017 10:51 AM
To: Dobbins, Roland <[email-masked]>; Jon Shallow <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Jon,

thanks,
Kaname

   functionality.

Dots mailing list

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

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 3 Aug 2017 09:14:49 +0100

Hi Tiru,

I agree that it is highly likely that a DDoS Attack will mutate over its
life time.  Reflections attacks (where the source port is constant - e.g. 53
or 123 udp) do not mutate so frequently in my experience and there is no way
to signal for that type of to be stopped currently.  The DOTS client may
continue to change its mitigation requests as the attacks evolve / mutate
which is fine from my perspective.

I really want to move away from Vendor Specifics for the more common
definitions so that there is a standard across all vendors - even if the
parameters are optional and are just hints.

I am not trying to re-create FlowSpec here in the signal  parameters, but
there (co-incidentally) is a large overlap.  FlowSpec does not support Uri,
but I think that is a good thing in dots-signal-channel.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 03 August 2017 08:58
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

The source IP addresses and source ports used by the DDoS attacker could
change, the type of attack itself could evolve or change from one attack
type to another.

It was discussed in the WG that this kind of information are only hints and
not mandatory to be conveyed by the DOTS client in the mitigation request.
https://tools.ietf.org/html/draft-ietf-dots-requirements-06 only discusses
conveying the mitigation scope and not the source or type of the attack.
However, DOTS signal channel draft allows vendor specific parameters and
reserved key values in the range of 32768 to 65536 for vendor specific
parameters, these hints can be conveyed as vendor-specific parameters to the
DOTS server.

-Tiru

Hi There,

Signal Channel

Data Channel

Questions

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 3 Aug 2017 08:44:13 +0000

Hi Jon,

We discussed various such hints including "attack details" in https://tools.ietf.org/html/draft-doron-dots-telemetry-00.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 1:45 PM
To: [email-masked]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Tiru,

I agree that it is highly likely that a DDoS Attack will mutate over its life time.  Reflections attacks (where the source port is constant - e.g. 53 or 123 udp) do not mutate so frequently in my experience and there is no way to signal for that type of to be stopped currently.  The DOTS client may continue to change its mitigation requests as the attacks evolve / mutate which is fine from my perspective.

I really want to move away from Vendor Specifics for the more common definitions so that there is a standard across all vendors - even if the parameters are optional and are just hints.

I am not trying to re-create FlowSpec here in the signal  parameters, but there (co-incidentally) is a large overlap.  FlowSpec does not support Uri, but I think that is a good thing in dots-signal-channel.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 August 2017 08:58
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Wednesday, August 2, 2017 3:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Signal / Data / Alias / Filter Implementation

Hi There,

Signal Channel

Data Channel

Questions

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 3 Aug 2017 10:00:54 +0100

Hi Tiru,

Thanks for the document pointer - a good read and reminds me of the initial
work I did with Nik Teague on getting DOTS started.

However, it is still unclear to me how the "DOTS Telemetry"
intelligence/hints can be conveyed over the signal and data channels using
what is currently defined, unless it is all done over the data channel using
ietf-dots-access-control-list.  My preferred option is that ietf-dots-signal
is extended to cover the more common attributes of an DDoS Attack.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 03 August 2017 09:44
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Jon,

We discussed various such hints including "attack details" in
https://tools.ietf.org/html/draft-doron-dots-telemetry-00.

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi There,

Signal Channel

Data Channel

Questions

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 3 Aug 2017 09:35:02 +0000

Hi Jon,

This draft was presented and discussed in the WG, but since DOTS telemetry is optional the feedback we got was to pursue this work later and there was no agreement in the WG on the common attributes of an DDoS attack and the protocol to convey this information (there were proposals to use DOTS signal channel, data channel and IPFIX).

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Thursday, August 3, 2017 2:31 PM
To: [email-masked]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Tiru,

Thanks for the document pointer - a good read and reminds me of the initial work I did with Nik Teague on getting DOTS started.

However, it is still unclear to me how the "DOTS Telemetry" intelligence/hints can be conveyed over the signal and data channels using what is currently defined, unless it is all done over the data channel using ietf-dots-access-control-list.  My preferred option is that ietf-dots-signal is extended to cover the more common attributes of an DDoS Attack.

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi There,

Signal Channel

Data Channel

Questions

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 3 Aug 2017 10:46:33 +0100

Hi Tiru,

I therefor propose to the WG that ietf-dots-signal (and its counterpart
ietf-dots-data-channel) is extended to cover the source-*, icmp types and
fragmentation as optional (and hint) entries to handle any future work in
Telemetry etc.

This simply would be extending the text in the appropriate places - agreed a
laborious job, but not rocket science.

New DDOS Attacks will be "created" and we need a way of being able to handle
them moving forward rather than what we have at present which is a
Destination RTBH with the added bonus of some extra destination fields
capability from the DOTS client - very limiting in my opinion.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 03 August 2017 10:35
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Jon,

This draft was presented and discussed in the WG, but since DOTS telemetry
is optional the feedback we got was to pursue this work later and there was
no agreement in the WG on the common attributes of an DDoS attack and the
protocol to convey this information (there were proposals to use DOTS signal
channel, data channel and IPFIX). 

-Tiru

Hi Tiru,

Regards

Jon

Hi Jon,

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi There,

Signal Channel

Data Channel

Questions

Regards

Jon

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 3 Aug 2017 18:57:14 +0900

Hi Tiru,

I see draft-ietf-dots-data-channel-02 includes appropriate reference to the latest draft-ietf-netmod-acl-model.

thank you,
Kaname

On 2017/08/03 17:06, Konda, Tirumaleswar Reddy wrote:
> *From:*Dots [mailto:[email-masked]] *On Behalf Of *kaname nishizuka
> *Sent:* Thursday, August 3, 2017 10:51 AM
> *To:* Dobbins, Roland <[email-masked]>; Jon Shallow <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Dots] Signal / Data / Alias / Filter Implementation
>
> Hi Jon,
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 3 Aug 2017 19:17:48 +0900

Hi Jon,

On 2017/08/03 16:56, Jon Shallow wrote:
>
> Hi Kaname,
>
> So as I read this, you are either extending the ietf-dot-signal definition to include source-* (and icmp, fragmentation and possibly rate-limiting) information or you are using Filters over the data channel (which is what Tiru is referring to). If it is an extension to ietf-dot-signal, then this needs to be formalised for interoperability between different suppliers.
>
The latter is my intention.  I'll check whether the alias mechanism which couples the data-channel and signal-channel works well.

> Similarly, ietf-dots-data-channel-identifier needs to be extended – but I do think the naming (e.g. target-ip instead of just ip) needs to be consistent between ietf-dot-signal and ietf-dots-data-channel-identifier.
>
+1.
a consistency of naming is important for readers.

thanks,
Kaname

> “5.3.1” of draft-ietf-dots-signal-channel would also need to reflect the ietf-dot-signal change. “6.” and “10.1.2” of draft-ietf-dots-signal-channel would also need CBOR to be updated with source-* etc. definitions.
>
> *From:*Dots [mailto: [email-masked]] *On Behalf Of *kaname nishizuka
> *Sent:* 03 August 2017 06:21
> *To:* Dobbins, Roland; Jon Shallow
> *Cc:* [email-masked]

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 3 Aug 2017 19:45:59 +0900

> The intent of DOTS is NOT to re-create flowspec.

Yes, I agree.

 > Getting into layer-4 traffic descriptors, including things like non-initial fragments, is re-creating flowspec and IPFIX.  We don't intend to do that.

 From ISP operator's perspective, DDoS mitigation includes RTBH, ACL, flowspec, dedicated box and cloud-type of service etc,..
As for flowspec, opening flowspec interface to other organizations is equal to passing responsibilities to other people, but DOTS is not.
DOTS should be able to cover the same problem space of flowspec in a safer manner, so giving layer-4 traffic information in data-channel is realistic for me.

thanks,
Kaname

On 2017/08/03 17:04, Roland Dobbins wrote:
> 'Taking out someone else's IP' is not a concern of DOTS itself; this has to do with the provisioning of the DOTS clients, servers, and associated detection/classification/traceback/mitigation systems.
>
> Getting into layer-4 traffic descriptors, including things like non-initial fragments, is re-creating flowspec and IPFIX.  We don't intend to do that.
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 03 Aug 2017 19:57:31 +0700

On 3 Aug 2017, at 16:46, Jon Shallow wrote:

>  to cover the source-*, icmp types and

It already should do so.

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 3 Aug 2017 14:05:33 +0100

>From Roland Dobbins
Sent: 03 August 2017 13:58

> >  to cover the source-*, icmp types and fragmentation as optional 
> > (and
> > hint) entries to handle any future work in Telemetry etc.

> It already should do so.

True if using ietf-access-control-list over data channel

Not true if using ietf-dots-signal over signal channel.

This extra functionality  is not available over the signal channel.

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 3 Aug 2017 13:21:52 +0000

Updated parameter names to be consistent b/w ietf-dots-signal and ietf-dots-data-channel in my local copy.

Added the following line to clarify the use of alias:
If the mitigation request contains both alias and other parameters identifying the target resource (such as, target-ip, target-prefix, fqdn, uri) then the DOTS server appends the parameter values in alias with the corresponding parameter values in target-ip, target-prefix, fqdn, uri parameters.

-Tiru
From: Dots [mailto:[email-masked]] On Behalf Of kaname nishizuka
Sent: Thursday, August 3, 2017 3:48 PM
To: Jon Shallow <[email-masked]>; [email-masked]
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Jon,

thanks,
Kaname

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of kaname nishizuka
Sent: 03 August 2017 06:21
To: Dobbins, Roland; Jon Shallow
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Jon,

thanks,
Kaname

   functionality.

Dots mailing list

Dots mailing list