Minutes for DOTS at IETF-96

Meeting Minutes DDoS Open Threat Signaling (dots) WG
Title Minutes for DOTS at IETF-96
State Active
Other versions plain text
Last updated 2016-08-19

Meeting Minutes

   ÿþ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

some responses

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

Bob: agree

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
middle term

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?

Jerome: yes

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.

8. Closing