Evangelos is in contact with the GRNET developers who originally developed FoD and continue to develop it further:
FoD REST API discussed: rule editing bug found by David verified; GRNET developers will provide a fix
Working plugin for rule statistics/graphs in available (productive in GRNET)
Update to Django 1.8 (was main issue found in Secure Code Review conducted by SA2-T1)
Ideas to switch from NETCONF to ExaBGP
=> desire to cooperate with T6 regarding further development of FoD
VC with GRNET developer of FoD: JRA2-T6 and GRNET group will exchange code and join FoD development/testing effort
JRA2-T6 has code for port-range support
GRNET has a new FoD version which fixes the issues in REST API found by David and also is based on newer version of Django library
GRNET will provide Virtual Router to test FoD with BGP FlowSpec+IPv6
Testing of new FOD features on FOD test machines
Fully tested the port range feature developed by Tomáš (with real traffic)
As well as the graphs statistics module and REST API by GRNET,
Extra software needed for fetching SNMP statistics of rules from routers and for creating image data out of it
Tomáš has started preliminary code for this based on JavaScript canvas and own SNMP collector for visualizing current statistics per rule
Already working, but performance needs to be improved and some details added
more precise value calculation
e.g graph labels
support for bytes, not only packets
multiple graphs (per router, not only summary)
For historic statistics, plan to use data/images from CACTI of GEANT
PSNC NOC (GEANT FoD user as well as own operator of a FoD instance for their network) asked for exchanging BGP FlowSpec rules via E-BGP: before deciding on this the implications for FoD have to be discussed in the task
DDoS Detection/Mitigation (D/M) WG
Fastnetmon testing at GARR:
Silvia and Nino are still working at there proposal for multi-domain use of fastnetmon where fastnetmon is used at institution side and can signal to upstream for mitigation based on local decision of
Actually they cooperate with other colleagues and also a range of users (with different operating/management requirements) in GARR to create a full POC together with them in GARR
GARR-internal meeting about Fastnetmon architecture (DDoS detection based on thresholds)
Detection based on traffic analysis using 1GB Intel card
As well as Juniper NetFlows: issues with timers still here: Fastnetmon documentation 10 sec vs. 60 sec currently on GARR Juniper routers; GARR has to find out whether this 60sec can be changed to 10 sec without problems
Blackholing system via RTBH on routers (IP address ranges announce by BGP)
Silvia/Nino still may send Tangui preliminarily draft of their proposal so than Tangui can get a idea and can compare both solutions
Crash of FlowMon which occurred some weeks ago was investigated and solved by fixing an issue mitigation script
A10 solution provides nice mitigation statistics during attack in GUI
But it is missing provision of mitigation statistics after the attack ended; A10 provides another product for this, aGalaxy, which would costs extra.
Nevertheless, A10 has a REST API to provide these current statistics during attack; Evangelos will check and try to test this API
Other from that testing is complete and was successful
Deepfield detection + A10 box mitigation testing
Serious bug fixed which prevented Deepfield from actual DDoS detection even 20 minutes after the attack
Still limitation which allow only one type of mitigation action to be applied to a single subnet: Deepfield put this on their roadmap
Deepfield put also on roadmap an import and store attack/rule statistics after an attack mitigated by A10 box
Other from that testing is complete and was successful
CORSA NSE7000 testing
Testing of NSE7000 mitigation box together with FlowMon detection system (via BGP FlowSpec) successful
Testing of NSE7000 mitigation box together with Deepfield detection system (via BGP FlowSpec) successful
Advantages of NSE7000 compared to white box Corsa OF switches (answer in VC with Corsa at 04.05.2017):
NSE7000 is 3 times faster in terms of packets/s
NSE7000 allows 200000 rules, number of bare OF rule would be less in white box switch
NSE7000 allows for a so-called (rule-global) Gigafilter, a list of IP address (prefixes) - capacity up to about full IPv4 routing table - which can be referred by a mitigation rule; could be applied in emergency situations to filter a very big DDoS attack with many source IP addresses explicitly
NSE7000 allows for copy action which allows to replicate selected packets (by rules; e.g. before filtering them) in hardware to another port; e.g. useful for debugging
NSE7000 will allow for layer-2 redirect action for selected packets
DDoS D/M Survey:
All polls ended
Up to now 22 answers from 20 different NRENs: general evaluation of answers:
balanced number of answers from managers, network engineers, and security engineers
FOD is very well known to the (answering) NRENs
Most of answering NRENs are using netflow-based DDoS detection
GEANT-provided scrubbing centre solution is desired by most of the answering NRENs (71.4%)
Further collaboration with other NRENs desired: experience sharing (35%) or even common development (40%)
More thorough analysis still to be done
Also plan to evolve the survey further towards specific questions about current/future FoD functionalities, also regarding long-term functionality beyond BGP FlowSpec mitigation
Evangelos will attend next TF-CSIRT meeting at 15.05.2017 and presents and discuss summary of survey results, also regarding FoD and A10 mitigation box usage in future
Certificate Transparency (CT)
CT Server
Working on v1.0
Started to write user/operator documentation
Various missing aspects: e.g. time zone support
Bugfixes for operational/technical issues found by DFN Cert/SUNET
Task-internal Demo/Presentation (user view of CT):
Now actual presentation has to be prepared
It should cover also the following strategic questions/aspects
What is the benefit of the service in general (use-cases/user stories, tangible examples why it is important, what will be the penalty if it is not there) and particular in GEANT case
What will be the role of GEANT/NRENs regarding it
How will it be run, by whom (GEANT/NREN), on which hardware
What would roughly be the effort needed to run an instance of the service: e.g. costs, man power over time, hardware, maintenance
Jerry, Linus, Magnus, and David will have an extra VC about this on 11.05.2017, 9:00-10:00 CEST
F2F Meeting Planning
New Foodle poll for F2F meeting exists, but answer may be hard if place of meeting not know (because of unclear voyage duration)
So, first the potential locations have to be found. Candidates currently are:
Garching near Munich (LRZ)
Prague: possible
Rome: possible, but only after Summer
Stockholm: possible (e.g. June)
Cambridge: possible
For each of these potential location everyone should check how long travel might potentially be for she/him
Next VC
In 6 weeks: 14.06.2017, 14:15-15:15 CE(S)T , as David is on meetings next two regular Wednesday dates David will contact everyone individually during these weeks.
Action items
Silvia/Nino: send Tangui preliminary slides about fastnetmon proposal draft
Silvia/Nino: provide proposal about multi-domain usage scenario for fastnetmon in wiki (e.g., at or below DDoS Detection/Mitigation WG File Area)
Silvia/Nino: if possible, provide some summary in wiki about Radware POC (e.g., at or below DDoS Detection/Mitigation WG File Area)
Linus/Magnus/David: internal presentation for CT use cases/service
all interested in DDoS D/M WG: fill new foodle
all: think about location and possibility to host F2F meeting
all: Next regular T6 VC: 14.06.2017, 14:15-15:15 CE(S)T
