Re: [Dots] Opsdir last call review of draft-ietf-dots-requirements-16

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Monday, November 26, 2018 1:02 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> Scott Bradner <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Opsdir last call review of draft-ietf-dots-requirements-16
> 
> 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.
> 
> Hi Tiru, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots [mailto:[e-mail]] De la part de Konda,
> > Tirumaleswar Reddy Envoyé : lundi 26 novembre 2018 06:16 À : Scott
> > Bradner; [e-mail] Cc :
> > [e-mail]; [e-mail];
> > [e-mail] Objet : Re: [Dots] Opsdir last call review of
> > draft-ietf-dots-requirements-16
> >
> > Hi Scott,
> >
> > Thanks for the review, Please see inline
> >
> > > -----Original Message-----
> > > From: Scott Bradner <[e-mail]>
> > > Sent: Sunday, November 25, 2018 2:03 AM
> > > To: [e-mail]
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]
> > > Subject: Opsdir last call review of draft-ietf-dots-requirements-16
> > >
> > > 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.
> > >
> > > Reviewer: Scott Bradner
> > > Review result: Has Nits
> > >
> > > This is an OPS-DIR review of Distributed Denial of Service (DDoS)
> > > Open
> > Threat
> > > Signaling Requirements (draft-ietf-dots-requirements)
> > >
> > > This document lists requirements for a protocol to used between
> > > providers
> > of
> > > DDOS mitigation services and users of such services, as such there
> > > can be
> > no
> > > direct operational issues with the document.  I also did not find
> > > any
> > indirect
> > > operational issues.
> > >
> > > I think the document would benefit from the addition of a section
> > > before
> > the
> > > requirements section that specifically describes the setup assumed
> > > by the document. The descriptions before there hint at a presumed
> > > setup but a new section that clearly states the setup would be
> > > helpful. (the setup appears
> > to be
> > > one where all network traffic to and from a protected entity flows
> > > through
> > a
> > > DDoS mitigation service provider.  The provider includes one or more
> > > DOTS servers.  The protected entity includes one or more DOTS
> > > clients that communicate with the DOTS servers)
> >
> > The requirements drafts refers to the DOTS architecture draft that
> > discusses the architectural relationships, components and concepts
> > used in a DOTS deployment.
> >
> > >
> > > Requirement SIG-005 addresses channel redirection – maybe there
> > > needs to be a way that clients can move to a new server on their own
> > > if they lose
> > hearbeat
> > > from the server they were using – that might include a way for a
> > > server to provide a list of alternative servers to the clients
> >
> > We can update SIG-004 requirement to say the following:
> >
> > The DOTS client may be provided with a list of DOTS servers.
> 
> [Med] IMHO given that the requirements I-D points to the architecture I-D, we
> don't need to be redundant:
> 
>    The DOTS client may be provided with a list of DOTS servers, each
>    associated with one or more IP addresses.  These addresses may or may
>    not be of the same address family.  The DOTS client establishes one
>    or more sessions by connecting to the provided DOTS server addresses.
> 
> But, of course it is not harmful to restate it if it helps the reader.
> 
>   If the DOTS
> > client considers the signal channel is defunct due to the extended
> > absence of DOTS server heartbeat, the DOTS client can establish  a new
> > DOTS signal channel with the other DOTS servers in the list.
> >
> 
> [Med] Some comments here:
> * I would not mix server selection/server migration with server redirection.
> That is, the proposed text is to be placed somewhere else in the I-D, not under
> SIG-004.
> * I would not describe the behavior (e.g., if xxx, establish a new session) in the
> Requirements I-D, but focus on the expected functionality if we really need to
> say something.
> * A DOTS client provisioned with multiple dots server may already have other
> sessions established. How those sessions are established is policy-based.
> * Establishing a new session should be carefully considered to avoid, e.g.,
> leaking information among servers not belonging to the same domain or
> oscillate between servers.
> 
> We can include a generic text such as the following:
> 
>   "Additional means to enhance the resilience of DOTS protocols, including
> when multiple DOTS servers are provisioned to the DOTS clients, SHOULD be
> considered."

Works for me.

-Tiru

> 
> 
> > -Tiru
> >
> > >
> >
> > _______________________________________________
> > Dots mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dots