Minutes IETF102: dots
minutes-102-dots-00

Meeting Minutes DDoS Open Threat Signaling (dots) WG
Title Minutes IETF102: dots
State Active
Other versions plain text
Last updated 2018-08-06

Meeting Minutes
minutes-102-dots

   DDoS Open Threat Signaling (DOTS) WG Agenda
IETF 102

THURSDAY, July 19, 2018
1550-1750  Afternoon Session II
Room: Van Horne (2)

Co-Chairs: Roman Danyliw, Liang Xia and Tobias Gondrom

1. Note well, logistics and introduction (chairs, 5 min)
- slides: https://datatracker.ietf.org/doc/slides-102-dots-chairs-summary/02/

- Agenda

o No agenda changes

- WG Document Status

Requirement: Shepherd write up
Architecture: WGLC on Monday (July 23rd)
Use Case: May need one more version for WGLC. Almost ready to shepherd write up
Signal Channel: Still has feedback on mailing list. Take another WGLC
Data Channel: WGLC on September

Flemming: We have a couple of pending changes for architecture. Hold on a
little on WGLC. Andrew: WGLC on August.

o Authors are updating and will post

2. Hackathon Report(s) (20 min)
- presenters: Kaname Nishizuka, Jon Shallow, Liang 'Frank' Xia
- slides:
https://datatracker.ietf.org/doc/slides-102-dots-ietf-102-hackathon-interop-report/00/

o Chairs thanked the hackathon team. They highlighted a number issues which can
be investigated.

Chair: Do the updated signal and data channel documents solve the Kaname's
issues? Med: Yes, these issues are fixed in the up to date documents. They are
just some clarification issues. I really appreciate the work which is done by
Kaname and the team. It help us to assess what we are putting in the document.
Kaname: Not only I but also Jon did a lot of work on the interpro testing.

Med: Question about mitigation on loss. How your implementation is behaving
right now? Andrew: Med refers the deadman's trigger, I am not sure you have
tested it. Kaname: We didn't test it, need ask Jon. Jon: In my interpretation
the deadman trigger was there if the was a loss of signal heartbeats between
the server and client. Then the server could initiate whatever he needed to
initiate to start mitigation as a consequence of the deadman's trigger. But
Andrew's email let me realized we don't have anything in place for what should
happen to start the mitigation Med: To avoid the confusion, perhaps we just
need to copy the most point from the architecture and put it into the signal
channel. Andrew: The issue for me is we don't defined what is the scope of the
mitigation actually when it is on the deadman's trigger. We can say that it
takes place on loss of signal in architecture draft. But there is no way to
tell the server based on the signal channel what the scope should be.

3. Implementation Report(s): (20 min)
- PoC of intra-domain DDoS Orchestration using go-dots (Yuhei Hayashi, 10 min)
- slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-poc-report-on-the-intra-domain-orchestration-use-case-01

Andrew: Whether you can send the top attackers information in the signal
channel or the data channel? Yuhei: I think it is signal channel. Med: We have
received the questions many times to add more information into the signal
channel. But now we decided to maintain the mandatory information. The new
information to be included in the signal channel is really optional to have.
Nik: Agree with Med that freeze the signal channel to a certain point. Then
yout build it into other drafts or other functionalities. Frank: Thanks for
bringing poc and requirements (DOTS Clients to send attacker information) here,
maybe future we can do some extensions. Please write a draft, so we can have a
discussion. Currently, the WG works on basic DOTS signal. Have the core thing
done, then we can do extension. Nik: There is nothing stop you from putting
this into the draft. Yuhei: We will write a draft and send to WG mailing list,
take comments from you Chairs: Take it to the mailing list

4. Signal Channel (20 min)
- draft: draft-ietf-dots-signal-channel-20
- slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-signal-channel-00
- presenter: Mohamed Boucadair

Next steps: get the last comments then we can move forward
- update for max-age:
Kaname: The updated text is not friendly to new readers. Some of the mailing
list discussion context should be included in the draft. Med: If you think that
is not clear in the new text, let me know then we can work on that. Chair:
Maybe Kaname can help to provide the text Med: I am personally fine with the
previous text. I decided to change the text becasue Jon has some confusion.

5. Adding DDoS Types for DOTS Signaling (10 min)
- draft-yang-dos-type-for-dots-00 (Bo Yang, 10 min)
- slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-adding-ddos-types-for-dots-signaling-00

Roland (Jabber): DOTS is not intended to be a full inter-vendor control
channel. There are infinitude type of possible DDoS attack types. Different
vendors use different paradigms. We should stick to signaling for now. Let's
take this up as a possible extension Kaname: It is not mature to include these
kind of DDoS types in the signal and data channel. Andrew: Support Roland and
Kaname. And there is a document defining different DoS type in the IETF, the
RFC4732. Bo: I got the information that IETF has DoS type definition. I will go
back to check that. Roland (Jabber): RFC 4732 obsolete, it shouldn't be used.
Andrew: He is correct. We have discussed something like this in the past. The
reason we didn't do it is that the dots client may not have the full scope of
attack. Bo: Yes, maybe the client do not have the whole information, or the
information is not fully trusted. But we just suggested it as a optional field
for reference. Andrew: Yes, I agree. I support this beyond the current
signaling draft.

6. Data Channel (25 min)
- draft-ietf-dots-data-channel-16
- slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-data-channel-00
- presenter: Mohamed Boucadair

Discuss the IPv4 fragmentation
Roman: This is one of the blockers to finish this document. The author would
very much benefit from your opinion. Andrew and Kaname: support the proposal.
Frank: Raise some discussion in mailing list. Jon: I would also like to see the
ability to have the bits and the mask capability of the TCP flags. Roman: We
have a little issues still to be resolved in -18. When we get -18, we will go
WGLC for this document.

7. Use Cases (25 min)
- draft: draft-ietf-dots-use-cases-13
- slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-dots-use-cases-00
- presenter: Daniel Migault

Chair:many versions were made, need time to review it. The author thought all
the feedbacks are covered. The chairs will do the final check to see whether
all the comments are addressed. Daniel: Yes, this is my feeling.

8. Closing (chairs, 5 min)
Next steps: signal channel -21 will go to 2nd WGLC, data channel will go to WGLC
There is more room for the enhancement work.