"go-dots" is a DDoS Open Threat Signaling (dots) implementation written in Go. This implmentation is based on the Internet drafts below.
- RFC9132 (was draft-ietf-dots-rfc8782-bis-08)
- RFC 8783 (was draft-ietf-dots-data-channel)
- draft-ietf-dots-architecture-18
- RFC 8612 (was draft-ietf-dots-requirements)
- draft-ietf-dots-use-cases-21
- draft-ietf-dots-signal-filter-control-07
- draft-ietf-dots-signal-call-home-09
- RFC9244 (was draft-ietf-dots-telemetry-25)
- draft-ietf-dots-robust-blocks-04
This implementation is not fully compliant with the documents listed above. For example, we are utilizing CoAP as the data channel protocol while the current version of the data channel document specifies RESTCONF as the data channel protocol.
Licensed under Apache License 2.0.
-
gcc 5.4.0 or higher
-
make, autoconf, automake, libtool, pkg-config, pkgconf or pkg-config
-
- go 1.18.1 or later is required. (for the latest GoBGP - v3.5.0)
- set PATH to go and set $GOPATH, using their instructions.
-
- OpenSSL 1.1.1g or higher (for libcoap)
-
MySQL 5.7.x and its development package (MySQL 8.0.x or higher not yet supported)
- Install mysql development package in Ubuntu: $ sudo apt-get install libmysqld-dev
-
gnuTLS (install to configure the certificate) $ sudo apt-get install gnutls-bin
- Ubuntu 16.04+
- macOS High Sierra 10.13+
To build libcoap for go-dots. We will work as follow:
- Pull and build libcoap. Currenly supported libcoap version : v4.3.1-rc1 (42d4f793a4be4a9fff0ad980bffa7528f6d639a7)
$ git clone https://github.com/nttdots/libcoap.git $ cd libcoap $ git checkout -b q-block origin/q-block $ ./autogen.sh $ ./configure --disable-documentation --with-openssl $ sudo make && sudo make install
$ go get -u github.com/gorilla/mux
To install go-dots source codes and command line programs, use the following command:
$ git clone https://github.com/amyllz/my-go-dots.git
$ cd go-dots
$ go mod download
$ make && make install
go-dots consists of 3 daemons below:
- dots_server: dots server agent
- dots_client: dots client specified in the Internet drafts
- dots_client_controller: The controller for the dots_client. Operators controll the dots_client by this controller
To explain the relationships between each daemons in detail, here we illustrates the mitigation request procedure of our system. First, dots_client_controller passes request JSONs to the dots_client. Examples of these JSONs are located in the 'dots_client/' directory in this Github project. Remember to edit the 'mitigation-id' fields in the JSON file every time you make requests to the dots_server. Then the dots client converts the received JSON to the CBOR format and send a mitigation request to the server via a CoAP connection.
The figure below shows the detailed sequence diagram which depicts how a dots_server handles a mitigation request.
Upon receiving CoAP messages, a dots_server first find the appropriate message controller for the received message. The message controller first find the customer information bound with the common name field contained in the client certificate. The customer information is configured and stored in the RDB before the server is started. To setup databases, refer to Setting up databases. If no appropriate customer objets is found, the dots_server decline the received request.
Then the server retrieves mitigation scopes contained in the received mitigation request message. Again the dots_server validate the mitigation scopes to determine whether the customer which issued the request has the valid privilege for the mitigation operations. If the validation is successfully completed, the server select a blocker for the mitigation and execute the mitigation.
Server Configuration is done by the system configuration file and the database setup. The system configuration file is specified via '-config' option when the 'dots_server' is invoked. The sample configuration files are located as 'dots_server/dots_server.yaml' and 'dots_server/dots_server.yaml.template'.
The blocker configuration of DOTS server is defined in database. For more detail about database, refer to the Database configuration document
$ $GOPATH/bin/dots_server --config [config.yml file (ex: go-dots/dots_server/dots_server.yaml)]
$ $GOPATH/bin/dots_client --server localhost --signalChannelPort=4646 --config [config.yml file (ex: go-dots/dots_client/dots_client.yaml)] -vv
After the go-dots is built, the mysql-notification.* MUST be copied from go-dots/mysql-udf to /usr/lib/mysql/plugin
$ sudo cp go-dots/mysql_udf/* /usr/lib/mysql/plugin
To install and run gobgp-server, refer to the following link:
Buid gobgp as below:
$ sudo chmod -R 777 $GOPATH/pkg/mod/github.com/osrg/gobgp/v3@v3.5.0
$ cd $GOPATH/pkg/mod/github.com/osrg/gobgp/v3@v3.5.0
$ go build -o $GOPATH/bin ./cmd/gobgp
$ go build -o $GOPATH/bin ./cmd/gobgpd
The Arista Server (Arista Switch Hardware) is installed and executed on Arista Extensible Operating System (EOS) platform. In order to connect to Arista Server, DOTS server use 'goeapi' open source library that is provided by Arista Networks company and the configuration file (.eapi.conf) which contains information about the Arista networks such as: host, username, password, etc.
[connection:arista]
host=arista
username=admin
password=123456
enablepwd=passwd
transport=https
For more detailed information about the configuration of 'goeapi', refer to the following link:
The primary purpose of the signal channel is for a DOTS client to ask a DOTS server for help in mitigating an attack, and for the DOTS server to inform the DOTS client about the status of such mitigation.
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Put \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123 \
-json go-dots/dots_client/sampleMitigationRequestDraft.json
In order to handle out-of-order delivery of mitigation requests, 'mid' values MUST increase monotonically. Besides, if the 'mid' value has exceeded 3/4 of (2**32 - 1), it should be reset by sending a mitigation request with 'mid' is set to '0' to avoid 'mid' rollover. However, the reset request is only accepted by DOTS server at peace-time (have no any active mitigation request which is maintaining).
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Put \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=0 \
-json go-dots/dots_client/sampleMitigationRequestDraft.json
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Get \
-cuid=dz6pHjaADkaFTbjr0JGBpw
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Get \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Get \
-cuid=dz6pHjaADkaFTbjr0JGBpw -targetProtocol=17 -aliasName=https1
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Get \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123 -targetPrefix=1.2.0.10/32
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Get \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123 -c=c
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Delete \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123
A DOTS client can convey the 'observe' option set to '0' in the GET request to receive notification whenever status of mitigation request changed and unsubscribe itself by issuing GET request with 'observe' option set to '1'
Subscribe for resource observation:
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Get \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123 -observe=0
Unsubscribe from resource observation:
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Get \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123 -observe=1
Subscriptions are valid as long as current session exists. When session is renewed (e.g DOTS client does not receive response from DOTS server for its Ping message in a period of time, it decided that server has been disconnected, then re-connects), all previous subscriptions will be lost. In such cases, DOTS clients will have to re-subscribe for observation. Below is recommended step:
・GET a list of all existing mitigations (that were created before server restarted)
・PUT mitigations one by one
・GET + Observe for all the mitigations that should be observed
A DOTS client can convey the 'If-Match' option with empty value in the PUT request to transmit DOTS mitigation efficacy update to the DOTS server:
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Put \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123 -ifMatch="" \
-json go-dots/dots_client/sampleMitigationRequestDraftEfficacyUpdate.json
DOTS client to DOTS server mitigation efficacy DOTS telemetry attributes
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Put \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123 -ifMatch="" \
-json go-dots/dots_client/sampleMitigationEfficacyTelemetryAttributes.json
$ $GOPATH/bin/dots_client_controller -request session_configuration -method Put \
-sid 234 \
-json go-dots/dots_client/sampleSessionConfigurationDraft.json
In order to handle out-of-order delivery of session configuration, 'sid' values MUST increase monotonically.
$ $GOPATH/bin/dots_client_controller -request session_configuration -method Get
$ $GOPATH/bin/dots_client_controller -request session_configuration -method Get \
-sid 234
$ $GOPATH/bin/dots_client_controller -request session_configuration -method Delete \
-sid 234
DOTS signal channel session configuration supports 2 sets of parameters : 'mitigating-config' and 'idle-config'. The same or distinct configuration set may be used during times when a mitigation is active ('mitigating-config') and when no mitigation is active ('idle-config'). Dots_client uses 'idle-config' parameter set by default. It can be configured to switch to the other parameter set by client_configuration request
Configure dots_client to use 'idle-config' parameters
$ $GOPATH/bin/dots_client_controller -request client_configuration -method POST \
-json go-dots/dots_client/sampleClientConfigurationRequest_Idle.json
Configure dots_client to use 'mitigating-config' parameters
$ $GOPATH/bin/dots_client_controller -request client_configuration -method POST \
-json go-dots/dots_client/sampleClientConfigurationRequest_Mitigating.json
Configure dots_client with heartbeat parameter
$ $GOPATH/bin/dots_client_controller -request client_configuration_heartbeat -method POST \
-json go-dots/dots_client/sampleClientConfigurationRequest_HeartBeat.json
Configure dots_client with qblock parameter
$ $GOPATH/bin/dots_client_controller -request client_configuration_qblock -method POST \
-json go-dots/dots_client/sampleClientConfigurationRequest_QBlockOption.json
Configure dots_client with block parameter
$ $GOPATH/bin/dots_client_controller -request client_configuration_block -method POST \
-json go-dots/dots_client/sampleClientConfigurationRequest_BlockOption.json
The primary purpose of the data channel is to support DOTS related configuration and policy information exchange between the DOTS client and the DOTS server.
All shell-script and sample json files are located in below directory: $ cd go-dots/dots_client/data/
Get root resource:
$ ./do_request_from_file.sh GET https://SERVER_NAME/.well-known/host-meta
Example:
- Request: $ ./do_request_from_file.sh GET https://127.0.0.1:10443/.well-known/host-meta
- Response:
<XRD xmlns="https://127.0.0.1">
<Link rel="restconf" href="https://127.0.0.1:10443/v1/restconf"></Link>
</XRD>
"{href}" value will be used as the initial part of the path in the request URI of subsequent requests
Registering DOTS Clients
Post dots_client:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} POST {href}/data/ietf-dots-data-channel:dots-data sampleClient.json
Put dots_client:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} PUT {href}/data/ietf-dots-data-channel:dots-data/dots-client=123 sampleClient.json
Uregistering DOTS Clients
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} DELETE {href}/data/ietf-dots-data-channel:dots-data/dots-client=123
Create Aliases
Post alias:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} POST {href}/data/ietf-dots-data-channel:dots-data/dots-client=123 sampleAlias.json
Put alias:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} PUT {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases/alias=xxx sampleAlias.json
Retrieve Installed Aliases
Get all aliases without 'content' parameter (default is get all type attributes, including configurable and non-configurable attributes):
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases
Get all aliases with 'content'='config' (get configurable attributes only):
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases?content=config
Get all aliases with 'content'='nonconfig' (get non-configurable attributes only):
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases?content=nonconfig
Get all aliases with 'content'='all'(get all type attributes, including configurable and non-configurable attributes):
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases?content=all
Get specific alias without 'content' parameter:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases/alias=https1
Get specific alias with 'content'='config':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases/alias=https1?content=config
Get specific alias with 'content'='nonconfig':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases/alias=https1?content=nonconfig
Get specific alias with 'content'='all':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases/alias=https1?content=all
Delete Aliases
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} DELETE {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/aliases/alias=https1
Retrieve DOTS Filtering Capabilities
Get Capabilities without 'content' parameter:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/capabilities
Get Capabilities with 'content'='config':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/capabilities?content=config
Get Capabilities with 'content'='nonconfig':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/capabilities?content=nonconfig
Get Capabilities with 'content'='all':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/capabilities?content=all
Install Filtering Rules
Post acl:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} POST {href}/data/ietf-dots-data-channel:dots-data/dots-client=123 sampleAcl.json
Post acl with insert:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} POST '{href}/data/ietf-dots-data-channel:dots-data/dots-client=123?insert=first' sampleAcl.json
Post acl with insert and point:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} POST '{href}/data/ietf-dots-data-channel:dots-data/dots-client=123?insert=after&point=xxx' sampleAcl.json
Put acl:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} PUT {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls/acl=xxx sampleAcl.json
Put acl with insert:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} PUT '{href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls/acl=xxx?insert=last' sampleAcl.json
Put acl with insert and point:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} PUT '{href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls/acl=xxx?insert=before?point=xxx1' sampleAcl.json
Retrieve Installed Filtering Rules
Get all Acl without 'content' parameter:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls
Get all Acl with 'content'='config':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls?content=config
Get all Acl with 'content'='nonconfig':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls?content=nonconfig
Get all Acl with 'content'='all':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls?content=all
Get specific acl without 'content' parameter:
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls/acl=sample-ipv4-acl
Get specific acl with 'content'='config':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls/acl=sample-ipv4-acl?content=config
Get specific acl with 'content'='nonconfig':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls/acl=sample-ipv4-acl?content=nonconfig
Get specific acl with 'content'='all':
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls/acl=sample-ipv4-acl?content=all
Remove Filtering Rules
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} DELETE {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/acls/acl=sample-ipv4-acl
Create vendor-mapping
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} POST {href}/data/ietf-dots-data-channel:dots-data/dots-client=123 sampleVendorAttackMapping.json
Update vendor-mapping
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} PUT {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/ietf-dots-mapping:vendor-mapping/vendor-id=345 sampleVendorAttackMapping.json
Get vendor-mapping of server
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/ietf-dots-mapping:vendor-mapping
Get vendor-mapping
Get vendor-mapping with 'depth'
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/ietf-dots-mapping:vendor-mapping?depth=3
Get vendor-mapping with 'content'
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/ietf-dots-mapping:vendor-mapping?content=all
Get vendor-mapping without 'depth' and 'content'
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} GET {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/ietf-dots-mapping:vendor-mapping?content=all
Delete vendor-mapping
Delete one vendor-mapping
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} DELETE {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/ietf-dots-mapping:vendor-mapping/vendor-id=345
Delete all vendor-mapping
$ ./do_request_from_file.sh --client-cert {client-cert-path} --client-key {client-key-path} --ca-cert {ca-cert-path} DELETE {href}/data/ietf-dots-data-channel:dots-data/dots-client=123/ietf-dots-mapping:vendor-mapping
Unlike the DOTS signal channel, the DOTS data channel is not expected to deal with attack conditions. Therefore, when DOTS client is under attacked by DDoS, the DOTS client can use DOTS signal channel protocol to manage the filtering rule in DOTS Data Channel to enhance the protection capability of DOTS protocols.
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Put \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123 \
-json go-dots/dots_client/sampleMitigationRequestDraftControlFiltering.json
The DOTS signal channel Call Home identify the source to block DDoS attack traffic closer to the source(s) of a DDoS attack. when the DOTS client is under attacked by DDoS, the DOTS client sends the attack traffic information to the DOTS server. The DOTS server in turn uses the attack traffic information to identify the compromised devices launching the outgoing DDoS attack and takes appropriate mitigation action.
$ $GOPATH/bin/dots_client_controller -request mitigation_request -method Put \
-cuid=dz6pHjaADkaFTbjr0JGBpw -mid=123 \
-json go-dots/dots_client/sampleMitigationRequestDraftCallHome.json
The telemetry aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal DDoS attack mitigation. The telemetry specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry contains Telemetry Setup Configuration
and Telemetry Pre-or-ongoing-mitigation
Registering telemetry configuration
$ $GOPATH/bin/dots_client_controller -request telemetry_setup_request -method Put -cuid=dz6pHjaADkaFTbjr0JGBpw -tsid=123\
-json go-dots/dots_client/sampleTelemetryConfiguration.json
Registering total pipe capacity
$ $GOPATH/bin/dots_client_controller -request telemetry_setup_request -method Put -cuid=dz6pHjaADkaFTbjr0JGBpw -tsid=123\
-json go-dots/dots_client/sampleTotalPipeCapacity.json
Registering baseline
$ $GOPATH/bin/dots_client_controller -request telemetry_setup_request -method Put -cuid=dz6pHjaADkaFTbjr0JGBpw -tsid=123\
-json go-dots/dots_client/sampleBaseline.json
Get one telemetry setup configuration
$ $GOPATH/bin/dots_client_controller -request telemetry_setup_request -method Get -cuid=dz6pHjaADkaFTbjr0JGBpw -tsid=123
Get all telemetry setup configuration
$ $GOPATH/bin/dots_client_controller -request telemetry_setup_request -method Get -cuid=dz6pHjaADkaFTbjr0JGBpw
Delete one telemetry setup configuration
$ $GOPATH/bin/dots_client_controller -request telemetry_setup_request -method Delete -cuid=dz6pHjaADkaFTbjr0JGBpw -tsid=123
Delete all telemetry setup configuration
$ $GOPATH/bin/dots_client_controller -request telemetry_setup_request -method Delete -cuid=dz6pHjaADkaFTbjr0JGBpw
Registering telemetry pre-or-ongoing-mitigation
$ $GOPATH/bin/dots_client_controller -request telemetry_pre_mitigation_request -method Put -cuid=dz6pHjaADkaFTbjr0JGBpw -tmid=123\
-json go-dots/dots_client/sampleTelemetryPreMitigation.json
Get one telemetry pre-or-ongoing-mitigation
$ $GOPATH/bin/dots_client_controller -request telemetry_pre_mitigation_request -method Get -cuid=dz6pHjaADkaFTbjr0JGBpw -tmid=123
Get all telemetry pre-or-ongoing-mitigation
$ $GOPATH/bin/dots_client_controller -request telemetry_pre_mitigation_request -method Get -cuid=dz6pHjaADkaFTbjr0JGBpw
Get one telemetry pre-or-ongoing-mitigation with query
$ $GOPATH/bin/dots_client_controller -request telemetry_pre_mitigation_request -method Get -cuid=dz6pHjaADkaFTbjr0JGBpw -tmid=123 -targetProtocol=17
$ $GOPATH/bin/dots_client_controller -request telemetry_pre_mitigation_request -method Get -cuid=dz6pHjaADkaFTbjr0JGBpw -tmid=123 -c=a
Get all telemetry pre-or-ongoing-mitigation with query
$ $GOPATH/bin/dots_client_controller -request telemetry_pre_mitigation_request -method Get -cuid=dz6pHjaADkaFTbjr0JGBpw -targetProtocol=17
Delete one telemetry pre-or-ongoing-mitigation
$ $GOPATH/bin/dots_client_controller -request telemetry_pre_mitigation_request -method Delete -cuid=dz6pHjaADkaFTbjr0JGBpw -tmid=123
Delete all telemetry pre-or-ongoing-mitigation
$ $GOPATH/bin/dots_client_controller -request telemetry_pre_mitigation_request -method Delete -cuid=dz6pHjaADkaFTbjr0JGBpw
To set up your database, refer to the Database configuration document
The 'dots_server' accesses the 'dots' database on MySQL as the root user.
$ cd go-dots/
$ mysql -u root -p dots < ./dots_server/db_models/test_dump.sql
Or you can run MySQL on docker.
$ cd go-dots/
$ docker run -d -p 3306:3306 -v ${PWD}/dots_server/db_models/test_dump.sql:/docker-entrypoint-initdb.d/test_dump.sql:ro -e MYSQL_DATABASE=dots -e MYSQL_ALLOW_EMPTY_PASSWORD=yes mysql
DOTS server listens to DB notification (e.g changes to mitigation_scope#status) at port 9999. If you want to change to different port, you have to change it at two places:
- dots_server/dot_server.yaml: dbNotificationPort: 9999
- mysql_udf/mysql-notification.c: #define PORT 9999
After changing port number, it is neccessary to rebuild go-dots (which includes rebuilding mysql-notification.c and restarting DB) so that the change can take effect.
$ cd go-dots/
$ make && make install
Check the route is installed successfully in gobgp server
$ gobgp global rib
Network Next Hop AS_PATH Age Attrs
*> 172.16.238.100/32 172.16.238.254 00:00:42 [{Origin: i}]
Check the active Arista ACL that is installed successfully in Arista server
$ show running-config interfaces Ethernet 1
interface Ethernet1
description DDoS-Seg-to_internet
ip address 172.16.238.100/30
ip access-group mitigation-acl-1 in
Check the active rules in Arista ACL that is installed successfully in Arista server
$ show ip access-lists mitigation-acl-1
IP Access List mitigation-acl-1
10 deny 4 any 1.1.2.0/24
20 deny 4 any host 1.1.1.69
Check the flowspec route is installed successfully in gobgp server
$ gobgp global rib -a ipv4-flowspec
$ gobgp global rib -a ipv6-flowspec
Network Next Hop AS_PATH Age Attrs
*> [destination: 1.1.2.0/24][protocol: ==tcp][destination-port: >=443&<=800] fictitious 00:00:06 [{Origin: i} {Extcomms: [redirect: 1.1.1.0:100]}]
- The GnuTLS has been installed.
Typically, the client's/server's certificate is a single identifier type which means that the certificate has only one common name (CN-ID) as identifier. However, the Common Name is not strongly typed because the Common Name can contain a human-friendly string, not a DNS domain name. Moreover, the client's/server's certificate can be multi identifiers type which including the Common Name (CN-ID) and some Subject Alternative Name (DNS-ID, SRV-ID), in order to ensure that at least one DNS qualified domain name. In go-dots, two certificate types are configured as below:
-
The single identifier type
The template file only has the Common Name (CN-ID)
Example: In file template_client, configure as follow:
# X.509 server certificate options organization = "sample client" state = "Tokyo" country = JP cn = "client.sample.example.com" expiration_days = 365 # X.509 v3 extensions signing_key encryption_key
-
The multi identifiers type
The template file has the Common Name (CN-ID) and some Subject Alternative Name (DNS-ID, SRV-ID)
Example: In file template_client, add more Subject Alternative Name as follow:
# DNS name(s) of the server dns_name = "xample1.example.com" dns_name = "_xampp.example.com
To add/change the server's certificate or the client's certificate, execute with following command:
./update_keys.sh
For more detailed information about configuration of the certificate and the GnuTLS, refer to the following link:
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
To install kubernetes, refer to the following link:
To setup and run the go-dots server and go-dots client on Kubernetes. Following as below:
-
Starting the virtual machine minikube
$ minikube start
-
Created the dots folder to Mount it to minikube. The dots folder contains the certs folder and the config folder. The certs folder contains the cert files in the certs folder. The config folder contains the test_dump.sql, the gobgpd.conf, the dots_server.yaml and the dots_client.yaml. The structure of the dots folder as below:
~/dots |--/certs |-- /certs/* files |--/config |-- /test_dump.sql |-- /gobgpd.conf |-- /dots_server.yaml |-- /dots_client.yaml
-
Mounting the dots folder from host directory to minikube. Then the host directory and the virtual machine minikube contain the dots folder with the files and the values of files that are same.
$ minikube mount ~/dots:/dots
-
Created the go-dots client, the go-dots server, the mysql and the gobgp on Kuberbetes by the Pod.yaml file
$ kubectl create -f Pod.yaml
-
Get Pod to check ip address of the go-dots server and the go-dots client
$ kubectl get pods --output=wide
-
Executing the container in the cluster by specifying the Pod name
- The go-dots client
$ kubectl exec -it client /bin/bash
- The go-dots server
$ kubectl exec -it server /bin/bash
- The mysql
$ kubectl exec -it server -c mysql /bin/bash
- The gobgp
$ kubectl exec -it server -c gobgp /bin/bash
- The go-dots client
-
After executing the go-dots server container. In the go-dots server container, you to do as below:
- Building the go-dots
$ cd go-dots $ make && make install
- Copy the mysql_udf/* to /usr/lib/mysql/plugin to the go-dots server listens to DB notification
$ sudo cp go-dots/mysql_udf/* /usr/lib/mysql/plugin
- Run the go-dots server
$ cd /dots/config $ $GOPATH/bin/dots_server --config dots_server.yaml -vv
- Building the go-dots
-
After executing the mysql container. In the mysql container, restored the
dots
database from the mysql dump file$ cd /dots/config $ mysql -u root -proot dots < test_dump.sql
-
After executing the gobgp container. In the gobgp container, run gobgp:
$ cd /dots/config $ sudo $GOPATH/bin/gobgpd -f gobgpd.conf
-
After executing the go-dots client container. In the go-dots client container, run the go-dots client:
$ cd /dots/config $ $GOPATH/bin/dots_client --server `ip address of the go-dots server` --signalChannelPort=4646 --config dots_client.yaml -vv
-
If you want to change port (signalchannel, datachannel) to different port in dots_server.yaml, you have to change it at two places:
- ~/dots/config/dot_server.yaml: signalChannelPort: 4646
- ~/dots/config/dot_server.yaml: dataChannelPort: 10443
-
If you want to change port (signalchannel, datachannel) to different port in Pod.yaml, you have to change it at two places:
- /docker/Pod.yaml: containerPort: 4646
- /docker/Pod.yaml: containerPort: 10443
-
If you want to change the fields in dots_server.yaml, you have to change it at '~/dots/config/dots_server.yaml'
-
If you want to insert new dots_client, you to do as below:
- In the mysql container, Insert new dots_client into database
$ mysql -u root -proot >mysql use dots; >mysql INSERT INTO `customer` (`id`, `common_name`, `created`, `updated`) VALUES (129,'client.sample.com','2017-04-13 13:44:34','2017-04-13 13:44:34'),
- Next, In the '~/dots/certs/' folder add client certification as the
Certificate Configuration
above
- In the mysql container, Insert new dots_client into database