Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-05.txt

[kaname nishizuka <[e-mail]>]

Hi Tiru,


On 2016/08/08 15:46, Tirumaleswar Reddy (tireddy) wrote:
> Hi Kaname,
>
> Yes, DOTS data channel should also cover pre-provisioning. As per our discussion at IETF, will remove DOTS channel from this draft, and create a new draft and pick specific sections and JSON attributes from draft-nishizuka-dots-inter-domain-mechanism and include pre-provisioning.
OK, That's great.

> Please see inline
>
>> -----Original Message-----
>> From: kaname nishizuka [mailto:[e-mail]]
>> Sent: Friday, July 22, 2016 12:22 PM
>> To: Tirumaleswar Reddy (tireddy) <[e-mail]>; [e-mail]
>> Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-
>> transport-05.txt
>>
>> Hi Tiru,
>>
>> I have a comment on section 6.  DOTS Data Channel.
>>
>>    * Data channel is for bulk data exchanges
>>    * Rough Consensus @ Design Team Meeting: Data channel is for pre-
>> provisioning
> Yup.
>
>> I think we need 2 types of filtering.
>> 1. filtering which limit the scope of mitigation
>>    * example
>>        - if an organization have other sites from which only legitimate traffic in
>> coming and is afraid of false positive, the sites should be treated as a
>> exception of mitigation with white-list.
> Yes, white-list rules can also be created using the DOTS data channel discussed in the draft (see traffic-rate attribute defined in DOTS data channel).
>
>>        - if a service is working only on port 80, traffic destined to other port can
>> be dropped without any consideration.
> Yes, the above rule can also be provisioned during peacetime using the DOTS data channel proposed in the draft.
>
>>    * this type of filtering may be installed in pre-provisioning phase (on data
>> channel)
>>         - can be changed even while it is under attack
> What is the use case for changing these type of filters during the attack ?
One, human make mistakes.
Two, white-list type of filtering rule could need to be more specific in order to filter out the attack more precisely.


>>    Also there should be a limitation on a request
>>    * requests from DOTS clients should be limited
> It's an implementation detail, what do you suggest needs to be discussed in this draft ?
OK, it's an implementation detail.
I just wanted to point out that the DOTS server should not accept all of the filtering request from the DOTS client without checking the CIDR block of the DOTS clients' domain.

>>        - request for blocking, rate-limiting, etc.. can be another attack vector if the
>> request is spoofed.
> DOTS client has to authenticate to the DOTS server, how will DOTS requests be spoofed ?
As described above, the DOTS client can spoof the prefixes of filtering request (not the DOTS client's address itself) in order to block traffic not to its domain but to other organization.

>>        - limitation on possible range of target (=IP addresses/prefixes) should be
>> pre-defined per customer basis.
>>        - installed in pre-provisioning phase (on data channel)
>> 	
> Agreed.
>
>>    [note]:this filtering is required without regard to protection methods
> I did not get the above line, please clarify.
It was meant to say that "The range of target (=IP addresses/prefixes) in the requests from DOTS clients should be checked by DOTS server. It is independent of the protection methods the DOTS server will take."


>> 2. filtering instruction for mitigation
>>    * filtering of traffic is one of protection methods taken by mitigators
> Okay.
>
>>    * DOTS client can request filtering of traffic with desired action (blocking,
>> rate-limiting...)
>>    * instructed while it is under attack (on signaling channel)
> DOTS signaling channel does not signal filtering rules, it's the job of DOTS data channel.
>
>> Data model of Filtering Rules described in section 6 (DOTS Data Channel)
>> looks like type 2 of filtering.
> No, Filtering rules can be provisioned either before or during the attack.
> I will update the draft to clarify, currently the draft is only high-lighting the example of black-list rules provisioned during an attack.
Okay, I'll see that.

regards,
kaname

> -Tiru
>
>> So I think it looks like for signaling channel.
>>
>>
>> best regards,
>> kaname nishizuka
>>
>>
>> On 2016/07/06 9:46, Tirumaleswar Reddy (tireddy) wrote:
>>> Added new section https://tools.ietf.org/html/draft-reddy-dots-transport-
>> 05#section-8 to discuss about mutual authentication of DOTS Agents &
>> authorization of DOTS clients. Comments and suggestions are welcome.
>>> Cheers,
>>> -Tiru
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>> Sent: Wednesday, July 06, 2016 1:04 PM
>>> To: Prashanth Patil (praspati); Dan Wing (dwing); Mike Geller
>>> (mgeller); Robert Moskowitz; Mohamed Boucadair; Tirumaleswar Reddy
>>> (tireddy)
>>> Subject: New Version Notification for
>>> draft-reddy-dots-transport-05.txt
>>>
>>>
>>> A new version of I-D, draft-reddy-dots-transport-05.txt has been
>>> successfully submitted by Tirumaleswar Reddy and posted to the IETF
>>> repository.
>>>
>>> Name:		draft-reddy-dots-transport
>>> Revision:	05
>>> Title:		Co-operative DDoS Mitigation
>>> Document date:	2016-07-06
>>> Group:		Individual Submission
>>> Pages:		26
>>> URL:            https://www.ietf.org/internet-drafts/draft-reddy-dots-transport-
>> 05.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-reddy-dots-transport/
>>> Htmlized:       https://tools.ietf.org/html/draft-reddy-dots-transport-05
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-dots-transport-05
>>>
>>> Abstract:
>>>      This document specifies a mechanism that a DOTS client can use to
>>>      signal that a network is under a Distributed Denial-of-Service (DDoS)
>>>      attack to an upstream DOTS server so that appropriate mitigation
>>>      actions are undertaken (including, blackhole, drop, rate-limit, or
>>>      add to watch list) on the suspect traffic.  The document specifies
>>>      both DOTS signal and data channels.  Happy Eyeballs considerations
>>>      for the DOTS signal channel are also elaborated.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>> _______________________________________________
>>> Dots mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dots