IETF 95 ACE Meeting Agenda Friday, April 8, 2016, 10:00-12:30 Chairs: Roman Danyliw, Tobias Gondrom Meeting Minute Taker: Xia Liang (Frank) 1. Status update (chairs): Milestone has been modified and delayed. 2. WG use cases draft (Roland): - Not exhaustive, representative. - 02 will be a major re-factoring of document. - New use cases will combine components, exchanges, and processes. - combine inter operator use cases from another individual use cases drafts, and new co-authors linda dunbar: not clear what is the dots client? what capability it have? Roland: any devices have ip address, such as router, mitigation device, web server daemon, ... Daniel, Bob: will clarify the definition in 02 version 3. inter-domain use cases draft (Kaname): Flemming: how much of the delegation model is in scope here? Kaname: the minimal info should be the same for C2P and P2P, but the optional info maybe is not the same. Flemming: Multihop deligation call for mitigation. Move the mitigation closer to the attack. Roland: all the mitigation methods are out of scope of dots, maybe in i2nsf. Chris: clients do not see the mitigation methods, it's the DOTS server's decision. Daniel: also not sure about how to do the sharing between domains, the overlapping between DOTS and I2NSF should be clarified. Tobias(as chair): we will negotiate and cooperate with I2NSF for further analysis and conversation. linda: what do you mean about wrong of bgp flowspec? Kaname: not mean it. just say some bgp flowspec need be changed. 4. inter-domain problems and mechanisms draft (Kaname): Chris: no matter what use cases, the basic is dots client to dots server relation. DOTS client should only see DOTS server and call for help, and need not know and do more. Frank: you are right. but some difference exists about how to construct a coordinating system based on the basic relation. Roland: 1. topology isn't super important here. 2. different networks/operators may have different gear/capabilities - so prescritptive solutions are not as good. 'lowest common denonimator is important'. Flemming: disagree - possible at l7 for problems to require much more assitance/info. alexander lemon: diff tech will bring diff results Tobias (hat-off): lowest common denonimator is the basic principle. But for the customer (operators), more information can bring more benefits, so welcome more input and information for this part! Dave: is it useful to exchange dots server info to dots client? Frank: Your question makes sense mainlyfor the distributed architecture, but the problem is full bidirecitonal signaling exchange is a little bit complex. Maybe now we should make it simple that just client send its info and call for help to server, and let the server to make decision in the first stage. alexander lemon: be away from the hierarchy way! 5. dots requirements draft (Andrew): Frank:conflict detection and notification, and lookup caching need more clarificaion, what we can do for these parts? need more discussion on ML Flemming: DNS ttl ignoring? Bob: when network is attacked, we cannot rely on DNS system to lookup the address. Roland: peering for dots does not require dns/resolution. Daniel: question plus timestamp for lifetime quesiton Dave: Is it in scope of DOTS that DOTS client requests more detailed mitigation, such as: filtering part of the traffic. Andrew: out of scope most likely?? discuss! Roman: encourge more suggestions about data channel part contents! 6. dots architecture draft (Andrew): Roland: suggest to be conservation for current dots information, maybe in future we can add more. Tobias (as chair): how many people have read this draft? call for adoption 7. dots transport draft (Dan Wing): Dan: asking for feedback on CoAP vs http/etc Daniel: does json/cbor/etc make sense with coap? expand on why Dan: need more study? Andrew: like CoAP. but most of the texts in this draft about how to distribute filters is more about Restful, not so closely related with DOTS. Dan: agree chairs: happy eyeballs and coap need some discussion on ML and get consensus dave: eyeballs need more buf and response time, and maybe multiple success. also need to consider what data model will influence the transport protocol. Nik: support eyeballs Luyuan Fang: like CoAP. Daniel: make the transport protocol implementation simple. 8. inter-domain dots problems and mechanisms: (frank) Roland: IPFIX reimplemented across another channel. Why not just send IPFix as usual. Andrew: Uses HTTP and JSON. Does client run HTTP server? Frank: All server messages are responses to client messages. Luyuan: What about communicating also during good times? Tobias (hat-off): we need them. but is something in discussion. Firstly, we need to guarantee not to lose them. chairs and Nik: running code and current existing implementation are all important to help us succeed. Kaname: NTT has some inter implementation for some use cases, be pleased to share. 9. draft-moskowitz-dots-gre-00 (Bob) Dave:port can be another attack surface. suggest DOTS protocol to not have fixed port, or have some dynamic negotiated port. Flemming: it's interesting but suggest to focus on UDP 10. Introducing session layer considerations (Bob) - draft-moskowitz-dots-ssls-01 - draft-hares-i2nsf-slss-00 Roland: maybe a corner-case, but is real and important. Another options to solve the related problems is by provisioning, or OOB channel. Tobias (hat-off): have we outlined the alternated transport use case in our WG draft? Roland: not yet, but will do. Close of session.