| Time | Item | Who | Notes |
|---|
| | Firewall On Demand (FoD?) | | - (info page for FoD development https://wiki.geant.org/pages/viewpage.action?pageId=63965046)
- Evangelos is in contact with the GRNET developers who originally developed FoD and continue to develop it further:
- 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 10GB 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
- FlowMon DDoS Defender detection + A10 box mitigation testing
- 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.
|
