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

and for me

Scott

> On Nov 26, 2018, at 5:11 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> wrote:
> 
>> -----Original Message-----
>> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
>> Sent: Monday, November 26, 2018 1:02 PM
>> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
>> Scott Bradner <sob@sobco.com>; ops-dir@ietf.org
>> Cc: draft-ietf-dots-requirements.all@ietf.org; ietf@ietf.org; dots@ietf.org
>> 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:dots-bounces@ietf.org] De la part de Konda,
>>> Tirumaleswar Reddy Envoyé : lundi 26 novembre 2018 06:16 À : Scott
>>> Bradner; ops-dir@ietf.org Cc :
>>> draft-ietf-dots-requirements.all@ietf.org; ietf@ietf.org;
>>> dots@ietf.org 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 <sob@sobco.com>
>>>> Sent: Sunday, November 25, 2018 2:03 AM
>>>> To: ops-dir@ietf.org
>>>> Cc: draft-ietf-dots-requirements.all@ietf.org; ietf@ietf.org;
>>>> dots@ietf.org
>>>> 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
>>> Dots@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dots