Re: [Dots] WGLC for draft-dots-use-cases-19

[H Y <[e-mail]>]

Hi,

> OK. I prepared a proposal at: https://github.com/dotswg/dots-use-cases/pull/11/files
Thank you for the proposal. I agree with it too.

Thanks,
Yuhei

2019年8月8日(木) 16:14 <[e-mail]>:
>
> Hi Tiru,
>
> OK. I prepared a proposal at: https://github.com/dotswg/dots-use-cases/pull/11/files
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> > Envoyé : mercredi 7 août 2019 08:35
> > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; [e-mail]
> > Cc : Xialiang (Frank, Network Standard & Patent Dept)
> > Objet : RE: [Dots] WGLC for draft-dots-use-cases-19
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > <[e-mail]>
> > > Sent: Tuesday, August 6, 2019 7:06 PM
> > > To: Konda, Tirumaleswar Reddy
> > > <[e-mail]>; Valery Smyslov
> > > <[e-mail]>; [e-mail]
> > > Cc: Xialiang (Frank, Network Standard & Patent Dept)
> > > <[e-mail]>
> > > Subject: RE: [Dots] WGLC for draft-dots-use-cases-19
> > >
> > > This email originated from outside of the organization. Do not click
> > links or
> > > open attachments unless you recognize the sender and know the content is
> > > safe.
> > >
> > > Re-,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Konda, Tirumaleswar Reddy
> > > > [mailto:[e-mail]]
> > > > Envoyé : mardi 6 août 2019 15:08
> > > > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; [e-mail] Cc :
> > > > Xialiang (Frank, Network Standard & Patent Dept) Objet : RE: [Dots]
> > > > WGLC for draft-dots-use-cases-19
> > > >
> > > ...
> > > > > > > [Med] The recursive case is not covered in the current text. I
> > > > > > > don't
> > > > > > think we
> > > > > > > need to elaborate on this further.
> > > > > >
> > > > > > I don't understand why recursive case should be excluded in the
> > > > > > current text ?
> > > > >
> > > > > [Med] Because the use-case draft does not cover this: It only covers
> > > > > the
> > > > case
> > > > > of an orchestrator talking to local routers.
> > > >
> > > > My question is why shouldn't the use case draft cover this ?
> > >
> > > [Med] Isn't this captured with the following?
> > >
> > >    o  DDoS Mitigation System (DMS): A system that performs DDoS
> > >       mitigation.  The DDoS Mitigation System may be composed by a
> > >       cluster of hardware and/or software resources, but could also
> > >       involve an orchestrator that may take decisions such as
> > >       outsourcing partial or more of the mitigation to another DDoS
> > >
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > ^^
> > >       Mitigation System.
> > >
> > > And
> > >
> > >    Another typical scenario for this use case is the relation between
> > >    DDoS Mitigation Service Providers forming an overlay of DMS.  When a
> > >    DDoS Mitigation Service Provider mitigating a DDoS attack reaches it
> > >    resources capacities, it may choose to delegate the DDoS Mitigation
> > to
> > >    another DDoS Mitigation Service Provider.
> >
> > I missed above text, Thanks.
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >  However If orchestrator is enforcing
> > > > > > > > filtering rules on routers, it should create the black-list
> > > > > > > > rules based on the non-spoofed attacker IP address and not use
> > > > > > > > the spoofed victim IP addresses.
> > > > > > > >
> > > > > > >
> > > > > > > [Med] Agree. Whether the check is done at the orchestrator or by
> > > > > > > the
> > > > > > DMS,
> > > > > > > is not a new concern. The DMS has to proceed with these checks,
> > > > anyway.
> > > > > > I
> > > > > > > fail to see what is NEW and SPECIFIC to the offload scenario.
> > > > > >
> > > > > > In this case the check has to be done by orchestrator when
> > > > > > enforcing black-list rules not to penalize the spoofed victim IP
> > > > > > addresses and should be discussed in the new use case.
> > > > >
> > > > > [Med] This requirement has to be followed by the DMS, anyway. This
> > > > > is
> > > > not a
> > > > > new issue, Tiru.
> > > >
> > > > No, sending attack information to the DOTS server is not covered in
> > > > any of the WG documents.
> > > >
> > >
> > > [Med] The text is about "additional hints". This is all what DOTS is
> > about :-)
> >
> > Yes, but the NEW text is discussing conveying attack information for the
> > first time and it needs more details.
> >
> > >
> > > > >
> > > > >  I don't see any other use case in
> > > > > > the specification discussing offload scenario with propagating the
> > > > > > attack information and I recommend updating the text discussing
> > > > > > the above scenarios.
> > > > >
> > > > > [Med] We don't have a similar text for the DMS case because
> > > > > mitigation
> > > > is
> > > > > out of scope. I'm expecting to follow the some rationale for the
> > > > offload.
> > > >
> > > > If mitigation is out of scope, remove the following line:
> > > > Then the orchestrator can take further actions like requesting
> > > > forwarding nodes such as routers to filter the traffic.
> > >
> > > [Med] This sentence is similar to saying the "DMS starts mitigation" but
> > with
> > > more contextualized information for a network orchestrator. The sentence
> > > uses "can", "like" which is fine for illustration purposes. As a reader,
> > I prefer
> > > to leave it.
> >
> > I suggest to add more details discussed in the thread. Anyways, will leave
> > it to you and the authors to decide, and I am not objecting to progressing
> > the draft
> > without the proposed update.
> >
> > Cheers,
> > -Tiru
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots



-- 
----------------------------------
Yuuhei HAYASHI
08065300884
[e-mail]
[e-mail]
----------------------------------