Minutes IETF103: dots

Meeting Minutes DDoS Open Threat Signaling (dots) WG
Title Minutes IETF103: dots
State Active
Other versions plain text
Last updated 2018-11-17

Meeting Minutes

   DDoS Open Threat Signaling (DOTS) WG Minutes
IETF 103

THURSDAY, November 8, 2018
0900-1100  Morning Session I
Room: Meeting 1

Co-Chairs: Roman Danyliw and Liang Xia
Minute Taker: Wei Pan

1. Note well, logistics and introduction
presenters: chairs

The chairs summarized recent activities of the WG and the status of the drafts.

2. Interoperability and Hackathon Report
presenters: Kaname Nishizuka, Jon Shallow

Kaname Nishisuka presented the results of interop testing from the IETF 103

Comment: (Tiru Reddy) You should try DTLS/TLS 1.3.

Per Slide #7
Q: (Flemming Andreasen) After the client losing heartbeat from server, will it
try to contact another server? A: (Jon Shallow) If the server can't receive
heartbeat response from the client but can receive the heartbeat request, it
can still regard the client alive, and do the mitigation. A: (Flemming
Andreasen) One incorrect action may be the client concluding to initiate a new
DTLS session to the DOTS server or a new server, but it will not succeed. A:
(Jon Shallow) The client should using the existing channel whenever he's doing
any requests, and it should try to set up a new session. The spec doesn't
mention about an alternative server.

Per Slide #9:
Comment: (Flemming Andreasen) Option 1 makes sense. About option 2, if it
works, then why wouldn't it work over the data channel? A: (Tiru Reddy) Option
1 is good, you should propose a draft about it. A: (Roman Danyliw) Take more
discussion on option 1 to the mailing list.

Comment: (Jon Shallow) TLS 1.3 has been published out. DTLS 1.3 isn't out yet.
Everything in the interop was done with either TLS 1.2 or DTLS 1.2. A: (Ben
Kaduk) DLTS 1.3 is in working group last call.

3. Server Discovery
presenter: Tiru Reddy*
draft: draft-boucadair-dots-server-discovery-05

Tiru Reddy presented a draft that describes multiple approaches for DOTS server

Comment: (Frank Liang Xia -- as individual) In this draft, you have several
ways to do the server discovery. It seems you extend some existing protocols
and you have specific extension for these protocols. A: (Tiru Reddy) The only
extension is for DHCP restore.

Q: (Frank Liang Xia -- as individual) There are some guidelines or rules for
using the other existing protocols to do the server discovery, right? A: (Tiru
Reddy) Right. A: (Frank Liang Xia) We should be careful about the specific
protocol extension. I personally think we can have more discussion on the

Comment: (Flemming Andreasen) I think the overall problem space makes sense, we
do need to solve this. A: (Roman Danyliw -- as individual): +1.  This will help
people use DOTS, and I support this work moving forward.

4. Multihoming Deployment Considerations
presenter: Tiru Reddy*
draft: draft-boucadair-dots-multihoming-04

Tiru Reddy presented a draft that describes deployment considerations for DOTS
in a multi-homed environment.

Comment: (Roman Danyliw): As background, this draft was created to describe
multi-homed considerations originally in the use case, architecture and
requirement documents.  WG consensus was to remove this text and publish it as
a separate document.

(Roman Danyliw) How many people have read these two drafts?
-- No many.
-- Take discussion to the mailing list.

5. Cooperative DDoS mitigation between the Home network and ISP
presenter: Tiru Reddy*
draft: draft-reddy-dots-home-network-00

Tiru Reddy presented an additional use case for DOTs in the home network

Q: (Wei Pan) When NAT is on-path, the source address of the outgoing traffic
will be translated to a random external IP address by the NAT equipment, so how
do the DOTS client find the correct DOTS server? A: (Tiru Reddy) ISP assigns IP
addresses or prefixes to the home networks, so ISP is aware of from which home
network that the traffic is outgoing.

Comment: (Roman Danyliw -- as individual) I like this use case. I recommend you
include language in the privacy section to discuss what will and won't get
leaked to the ISP about the internal home network.

Comment: (Kaname Nishizuka) I support it. There may be a discussion about this
in a IPv6 use case. I think attack name/id conveyed by DOTS client is
diagnostic, the home routers may not be capable of handling emerging
sophisticated attacks, so I don't think such information is required. (Tiru
Reddy) It's just for diagnostic purpose.

Comment: (Frank Liang Xia -- as individual) This is a rarity use case. To
achieve this goal, the home network gateway which is a very limited device
should support DOTS server function. This is different from our previous
design, so I have some confusion about it. I also think the solution reflects
the idea that we need to do some near source attack mitigation, and this is the
key point of this draft. We have some other similar cases, like datacenter or
branch network. A: (Tiru Reddy) I think this solution is going to be useful for
various other use cases, and we can definitely update the draft. For some
vendors, we are adding a lot of capability to the home router, like limited IPS
function, IOT firewall function, etc. DOTS server on the home router is not a
public DOTS server, it is only for the intended DOTS client and there is going
to be only one DOTS connection, so the home router will not be overwhelmed. A:
(Frank Liang Xia) It will be very useful if you can provide more evidence or
observation from your side about this possibility in the mailing list. A: (Tiru
Reddy) Sure.

Comment: (Martin) I like the point previous speaker made with the key aspect of
mitigating attacks closer to the source. There are some countries where a net
neutrality imposes quite strict restrictions on what a telecom can do on home
user. I think it would be wise to tailor the functions on home gateway very
strictly to the use case of DDoS mitigation, but not for the generic firewall
or some dpi work, so that it may have a better chance of getting deployment in
such countries. A: (Tiru Reddy) I totally agree with you. We didn't want to
blindly block the traffic. This is pretty much specific for DDoS and we don't
want to be used for other purposes.

6. DDoS mitigation offload usecase and YANG module expansion in
   signal channel
presenter: Yuhei Hayashi
draft: draft-h-dots-mitigation-offload-expansion-00

Yuhei Hayashi presented an additional use case for DOTS with an orchestrator.

Q: (Roman Danyliw) Does the orchestrator wait for the network administrator to
take action? A: (Yuhei Hayashi) I divided the draft.

Q: (Tiru Reddy) Why the DMS must use DOTS to talk to the orchestrator?
A: (Yuhei Hayashi) I will discuss this on the mailing list.

Q: (Kaname Nishizuka) How many source IP addresses can be included?
A: (Yuhei Hayashi) In the draft now is 10, but not concrete.

Q: (Flemming Andreasen) Is it worthwhile to standardize the communication
between the DMS with the orchestrator? Why use signal channel to do that? A:
(Yuhei Hayashi) I will discuss this on the mailing list. A: (Jon Shallow) When
DMS has the trouble in pipe, it sends dots session request up to the
orchestrator, and the orchestrator can mitigate upstream what's taking place.

Comment: (Martin) The use case seems really helpful.

7. WG next steps

The chairs solicited feedback from the WG on interest in new work items.  No
new items were raised.

The remaining time was spent on open mic:

Q:(Kaname Nishizuka) Are there any connection among the server discovery,
multihoming consideration and the call home? What about server discovery in
local home use case. A:(Tiru Reddy) There is a connection between all the
three. Nowadays many of the home routers come with multiple interfaces and do
support multihoming. The home router needs to initially discover the DOTS
server. These three are not independent.

Comment: (Martin) I have a question for Yuhei on the mitigation offload use
case. I'm wondering if the signaling of what the client perceives to be attack
traffic and the offloading use case are actually bound tightly together or
whether they are good ideas on their own. A: (Yuhei Hayashi) Thanks for your
feedback, I will send revision to the mailing list.

Comment: (Ben Kaduk): I want to apologize to everybody that the AD review on
the signal channel and data channel are taking so long. I expected to be done
sooner. Comment: (Markovski) I apologize I haven't been in this working group
before. The new research group SMART has some overlap with DOTS. People who are
interested in SMART can join the planning meeting this evening.

Q: (Tiru Reddy) I have a question about DOTS implementation. I'm wondering has
anyone considered any mechanism for the crypto mechanisms & identities
provisioning of DOTS client and server for mutually authenticating each other.
Any one has any insights on it, or we should discuss it on the mailing list. A:
(Frank Liang Xia) You can do this on the mailing list. If we have enough
interest, we can do this kind of work. Also for today's individual drafts, I
think they all make sense, but we need more discussion and comments.

(Lawrence Muchilwa) I want to volunteer my time to anyone who might need help
with implementation.

8. Closing

The chairs summarized the WG discussion.