Minutes for DOTS at IETF-96
DDoS Open Threat Signaling
||Minutes for DOTS at IETF-96
ÿþDDoS Open Threat Signaling (DOTS) WG Agenda
Tuesday, July 19, 2016
1620-1820 Afternoon Session II
Bellevue SEC dots DDoS Open Threat Signaling WG
Co-Chairs: Roman Danyliw and Tobias Gondrom
1. Note well, logistics and introduction (chairs, 5 min)
Flemming: data model is still missing;
Frank: we have some related content in some solutio drafts;
Tobias: Are Flemming or other guys willing to do this work? Any other
2. Use Case Discussion (20 min)
- draft-ietf-dots-use-cases-02 (Roland Dobbins, 10 min)
Tobias: November is the WG Last Call milestone for this draft. If you have new
use cases, please submit them before November
Roland: -02 or even -03 will be prepared before the deadline, -02 is a major
Andrew: Is there working copy of the draft now?
Roland: we will send it to the list ASAP.
Roman: please help us to review the draft, and if you have ideas about new use
cases, please let us know.
Jabber: do not see version 2;
Roland: promises at least one update before November.
- Additional use cases discussion (10 min)
3. Requirements Discussion (20 min)
- draft-ietf-dots-requirements-02 (Andrew Mortensen, 10 min)
- Additional requirements discussion (10 min)
Roland: we will include the DOTS gateway (for intra or inter-domain) contents
in next use cases draft, hope it is helpful to imply the requirements.
Frank: Information model and data model is similar in the aspect for decribing
what information we need and their attributes, I don't think we need repeated
requirements for them.
Andrew: agree and thanks.
Flemming: Agree, don't get hung up on data and info models. staying at data
model is not the best idea.
4. Architecture Discussion (20 min)
- draft-ietf-dots-architecture-00 (Andrew Mortensen, 10 min)
- Additional architecture discussion (10 min)
Brian Rosen: most important learning from SIP gateway is that you must have
security on every hop if you expect end-to-end. You cannot have any unsecure
Bob: need geo-loc
Roland: not geo-loc, perhaps topology
Roland: looking at SRV records and anycast to find server
Roland: think about federation--call it out in arch doc. there are maybe two
stages for DOTS WG: 1--standardize the current proprietary interface for the
p2p connection, 2 -- have a federated coordination among peers in the neraly
Flemming: please say more about coordination response
Frank: in my dots protocol draft we mentioned two models: p2p and coordinated.
I think it can explain the possible models.
T. Reddy. Cisco: client should discover there are multiple upstream dots
servers so that we have 1-to-1 request/response.
Roland: real problem where customer must *manually* coordinate upstream
mitigation. We can improve automation if federation. coordination is necessary
for DOTS. coordination center can have more overall view of the network flow
and make good decision.
Flemming: more content is needed in requirements draft to make the two mode
Dave Dolson: is it intended to create a new session layer protocol? Vs. reuse
an existing like diameter?
Andrew: current thinking is to have a persistent connection
Roland: redirection has some value for ddos protection SPs, and anycast may be
useful to partly solve the redirected signaling problems.The question is
redirection has some operational issues we need to consider the tradeoff, such
as:reliability and resilience, since there can be a lot of nodes among the dots
client and dots server.
Flemming: redirected signaling is different from recursive signaling, it's more
explicitly to express the policy and action. we should consider both of them.
Tiru:the privacy concerns is not on the traffic, but on the contents of message
whether they should be known by upstream operators. The key is important.
Roland: I don't see the privacy concerns on the recursive model. recursive is
only to have more hop relation comparing redirected signaling
Roland: Mitigation issues: peer lost should be optional for mitigation trigger
condition, for there can be other reasons for peer lost. And the mitigation
initiation condition is more accurate and can be more broad than the current
5. Protocol Drafts (40 min)
- draft-reddy-dots-transport-05 (Tiru Reddy, 10 min)
Roman: which use cases are your solution draft covered?
Tiru: potentially all. we'll mention that on the draft.
Roland: dynamic feature like happy eyeball is important, though it is not the
first step (near future)
Tiru: it make senses for the use cases when DOTS server has dynamic address and
Andrew:can you explain the reason why you choose CoAP?
Tiru: CoAP fits well all the requirements about DOTS transport protocol
(congestion control, etc), it's an existing technology running over TCP and UDP
transport, so we don't need to reinvent a new one.
Andrew: Do you see any issues when a DOTS gateway is a B2B CoAP proxy?
Tiru: end to end encryption and authentication is very complicated, but hop by
hop authentication is enough and supported by CoAP.
- draft-francois-dots-ipv6-signal-option-00 (Jýÿrýÿme Franýÿois, 10 min)
Roman: how does the server know the messages switched from previous signaling
channel to the new channel?
Jerome: we have normal signaling channel, and the backup channel actually
watches traffic of normal channel.
Roman: It seems a bit tricky
Roland: is this solution the backup channel?
Roland : mechanisms that excessively relies on options are not the best one
Jerome: it's just another optional signaling channel, to increase the chances
of DOTS messages' transmit.
Flemming: 2 basic questions: what is the goal of the content included in ip
option attribute? if the DOTS regular can not arrive the DOTS server, how your
channel can achieve this?
Jerome: we will try every possible address and path to guarantee it.
- draft-fu-dots-ipfix-extension-01 (Alex Zhang, 10 min)
Roland: I agree there are some possible new works here. But we need to have a
clear understanding of current state of art, then identify the gaps, then
reopen the closed IPFIX WG related works. The proposed IEs in the draft is more
broad than current DOTS WG, it needs a broader concensus.
Tiru: current network devices and FWs do send this kind of telemetry
information for attack detection. Can you explain why you need those new IEs?
Tobias: we do see the benefits of using some new IEs for the network attack
detection. for the benefits of the industry, we want this information can be
vendor neutral, which means to be the standardized ones.
Roman: which use cases are covered, and are not covered?
Frank: we will clarify this in the draft (do citation in the draft).
- draft-nishizuka-dots-inter-domain-mechanism-01 (Frank Xia, 10 min)
chairs: no time for comments
6. Related Work (5 min)
- draft-mglt-i2nsf-ssf-collaboration-00 (Daniel Migualt, 5 min)
Tobias: does this draft relate to I2NSF?
Daniel: I guess so.
7. Open-Mic (10 min)
Chairs: we are hoping to see some running code, or implementation. So we will
have a interim meeting in Wednesday to discuss it.