* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dots Status Pages

DDoS Open Threat Signaling (Active WG)
Sec Area: Eric Rescorla, Kathleen Moriarty | 2015-Jun-26 —  

IETF-99 dots minutes

Session 2017-07-20 1550-1750: Berlin/Brussels - Audio stream - dots chatroom


minutes-99-dots-00 minutes

          DDoS Open Threat Signaling (DOTS) WG Agenda
          THURSDAY, July 20, 2017
          15:50-17:50,  Afternoon Session II
          Co-Chairs: Roman Danyliw and Tobias Gondrom
          1. Note well, logistics and introduction
          presenters: Roman Danyliw and Tobias Gondrom
          The chairs presented on the status of the working group.
          2. Use Case Discussion
          presenter: Roland Dobbins
          draft: draft-ietf-dots-use-cases-07
          Dobbins presented the status of the -07 use case draft.
          Comment: (Tobias Gondrom): This is a very new version, please review it
          and give your help on comments.
          Comment: (Flemming Andreasen): With the respect of the homenet use cases,
          what's your concern about the use cases?
          A: (Roland Dobbins): Because it is not sufficiently different from some
          aspects of several other use cases.
          A: (Flemming Andreasen): So it’s not the scenario that you feel isn't
          relevant, but that it isn't sufficient unique to the others?
          A: (Roland Dobbins): Yes
          Comment: (Artyom ?):
          I have three suggestions.
          (1) The first one is about the MSSP requesting assistance from other
          MSSP. It is important to review the work done by other work groups.
          (2) The second one is about the use cases in 3.2.1.suppression of outbound
          DDoS traffic originating from consumer broadband access network. It may
          contradict with the group charter which says the WG will focus on the
          signaling and coordination mechanisms directly related to DoS attack
          detection, classification traceback and mitigation.
          (3) The third one is that the draft on github hasn’t been updated to
          the latest version.
          A: (Roland Dobbins): To your first of your comment, if you can give us
          some pointers on the list that would be helpful. With the regards to the
          outbound DDoS issue, it is a distinct use case from other types of bad
          traffic emanating from broaband access network.  Broadband operators spend
          lots of time dealing with this and suppressing outbound DDoS attacks
          in many different ways.  The idea of this use case is to illustrate
          that DOTS could be used to signal for the mitigation action. Secondly,
          it also offers the ability actually quarantine potentially nodes which
          are launching lots of outbound DDoS attack.
          Q: (Kathleen Moriarty as AD): what is the plan for the use cases draft?
          A: (Roman Danyliw): Publish the use cases, requirements and the
          architecture as separate informational documents.
          A: (Roman and Tobias): The WG has indicated that the use cases,
          requirements, architecture drafts are all very valuable for readers to
          understand the protocols.
          3. Requirements Discussion
          presenter: Robert Moskowitz
          draft: draft-ietf-dots-requirements-06
          Moskowitz provided an updated on the -06 requirements draft.
          Comment: (Artyom ?):
          The definition of client signal limits the scope of a requested
          mitigation.  In the draft, the DOTS client is described as a decision
          maker. But in the case of DoS attack, the bandwidth is consumed so that
          the victim/client side can only see a limited number of data. Hence the
          DOTS client may not be a good decision maker because it doesn't have
          enough data.
          A: (Bob Moskowitz): I will say this is an advisory message. Though the
          client says I see this attack, the server says the attack is really
          something else. The server having broader view can see something much
          A: (Andrew Mortensen): To the point that the server must see the
          mitigation. I believe the text says the server can continue mitigation
          but the client is no longer responsible for that mitigation.  There are
          likely service agreements to describe business relationships between
          the client and server.
          A: Please send you specific comments in mailing lists and the github,
          so that we can discuss it openly and track the modification
          Comment: (Roland Dobbins): we previously have the use cases of dots server
          cannot receive the message, we can bring that use case back. Besides,
          dots does not consider specific DDoS detection, classification, tracebacck
          and mitigation techniques.
          Dots Chairs: How many people have read this requirements draft? Seems
          like many.
          Dots Chairs: what's the timeline for the next new version?
          A: (Andrew Mortensen): early next week.
          4a. Architecture: draft-ietf-dots-architecture-04
          presenter: Nik Teague
          draft: draft-ietf-dots-architecture-04
          Teague provided an update on the -04 architecture draft.
          4b. Architecture: draft-boucadair-dots-multihoming-01
          presenter: Mohamed Boucadair
          draft: draft-boucadair-dots-multihoming-01
          Boucadair introduced this new draft on handling multi-homing in the DOTS
          Comment: (Roland Dobbins): Use cases, requirements and architectures
          are worked in parallel with one another and informed one another
          bilaterally. But we do not anticipate any new requirements that have
          not already been anticipated and discussed in these documents from
          last version. some new use cases need new contents in requirements and
          architecture draft.
          Nik: will look at it.
          Q: (Flemming Andreasen): (1). We want to address the simple scenarios
          first. So do you think the multihoming is an absolute requirement for
          what we are doing in the first step in DOT to address. (2) Do you want
          to standardize what DOTS gateway is? I don't think we want to do it.
          Comment: (Roman Danyliw): thank you Mohamed for elaborating on the
          multi-homing topic and write a draft.  We've discussed it at the interim
          Comment: (Flemming Andreasen): As a general rule, we're trying to address
          the simple use cases first.  This the multi-homing is a more complex
          use cases.
          A: (Mohamed Boucadair): Agree the step by step way to do the protocol,
          multi-homing problems can be solved later. And there is no dots gateway
          in current architecture, it's just dots client + server.
          A: (Tobias Gondrom): if you think any features are essential, please
          solve it right now. we will not wait for next stage to do it.
          A: (Roland Dobbins): to support multi-homing is a hard requirement for
          DOTS protocol.
          A: (Flemming Andreasen): there are various multi-homing use cases,
          how can I know in advance the specific use cases in network?
          A: (Mohamed Boucadair): indeed, it is learned by some provision work.
          Comment: (Roland Dobbins): lots of your content are the operational
          thing, but are out of DOTS protocol scope. We can add some description
          about this part since they are useful.
          Chairs: suggest to add the multi-homing contents into existing
          requirements and architecture draft. As of yet, the multi-homing problems
          are still not clear for WG, please discuss them in mailing list until
          we have a more clear picture about it.
          5a. Protocol: IETF 99 Hackathon Activity
          presenter: Kaname Nishizuka
          Nishizuka presented on his experiences and insights with implementing
          the DOTS protocols during the hackathon.
          Chairs: Great work at the hackathon! Thank you Kaname!  We'd like to
          see more implementations and perhaps an interoperate test in Singapore.
          Comment: (Roland Dobbins): from operational perspective I would support
          relaxing the heartbeat requirements you showed.
          A: (Artyom ?): be careful with dropping the zero heartbeat mode
          A: (Andrew Mortensen): I'm wondering if it will be sufficient to meet
          the requirement for two unique implementations that are interoperable.
          A: (Nik Teague): Echo some the discussion on the zero heartbeat
          idea. Should support zero heartbeat mode, but not necessary to be must.
          A: (Roland Dobbins): +1 on Nik
          Q: (Dave Dolson) Any concerns on the packet size during your test? for
          example, json, cbor, xml, etc?
          Chairs: Polling the room, 4-5 companies (purposefully not named in the
          minutes) are interested to do the further hackathon together.  As a
          reminder open source or proprietary implementations are welcome to an
          5b. Protocol: draft-ietf-dots-signal-channel-02
                      : draft-ietf-dots-data-channel-02
          presenter: Nik Teague
          draft: draft-ietf-dots-signal-channel-02
          Teague presented an updated on the WG signal and data channel drafts.
          Q: (Roland Dobbins): What's the logic behind the thinking that it might
          make sense to do the mitigation session limitation during the session
          A: (Nik Teague): Can't recall. This is the first version so there
          may be some baggage and there is some changes occurred on a rolling
          basis. Something maybe overlap so I wouldn't put too much.
          Q: (Flemming Andreasen): A general question on both draft. It's not so
          clear to me when I look at these drafts exactly how the extensibility
          requirements are being satisfied.
          A: (Nik Teague): There is something I need to address it.
          5c. Protocol:
          presenter: Mohamed Boucadair
          draft: draft-boucadair-dots-server-discovery-02
          Boucadair introduced a new draft proposing an approach to conduct server
          Q: (Roland Dobbins): There is a lot of discussion on anycast here. It
          seems there is an assumption that anycast is going to be a very common
          addressing mechanism for DOTS server. What is the assumption based on?
          A: (Mohamed Boucadair): Read the DOTS architecture, it has message there.
          Comment: (Kaname Nishizuka): As a implementer we would like to keep the
          DOTS client simple.
          A: (Mohamed Boucadair): There is only a recommendation to implement all
          the steps there.
          Q: (Martin ?): Is there any mechanism to foreseen for bootstrapping
          Comment: (Bob Moskowitz): We should look at Netconf zero touch
          Comment: (Roland Dobbins): There needs to be some good discussion with
          the architecture and requirements work about all this.
          5e. Protocol: draft-francois-dots-ipv6-signal-option-02
          presenter: Jérôme François
          draft: draft-francois-dots-ipv6-signal-option-02
          François provided an update on a draft describing an alternative signal
          Q: (Roland Dobbins): What is the value of having an additional in band
          auxiliary channel?
          A: (Co-chair): Is that a new use case to talk about?
          A: (Co-chair): I'm also confused a little bit. I can see maybe I want to
          upload information to a server in case I'm going death or silent. But
          I'm not quite clear what's the benefit of uploading it somewhere else
          instead of uploading it to the server and so I'm not grasping what you
          try to solve. I am not seeing it as a strong requirements.
          6. Closing

Generated from PyHt script /wg/dots/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -