Subject: Re: [Dots] requirements clarifications needed

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 08:18:22 +0000

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, March 23, 2016 12:25 PM
> To: Tirumaleswar Reddy (tireddy); Roland Dobbins; dots
> Subject: RE: [Dots] requirements clarifications needed
> 
> Hi Tiru,
> 
> Redirecting a client to another server is a useful functionality for various
> operational reasons: e.g., the server instance is overloaded, redirect the
> client to a service-specific server (e.g., telephony), etc.
> 
> How redirection is triggered, is policy-based and deployment-specific.
> 
> How redirection is actually designed, is out of scope of the requirements
> document. That discussion should be left to solution document(s), IMHO. In
> particular, how redirection should be designed to avoid spirals/loops, etc.
> should be part of that space.

The points I raised in previous mails are not for the requirement draft. OP-003 in the requirement draft already discusses re-direction. It is to start discussions on how to design re-directions for DOTS, impact of re-direction during attack, multiple re-directions, re-direction to DOTS server in another domain and other problems like loops . 

-Tiru

> 
> Thank you.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots [mailto:[email-masked]] De la part de Tirumaleswar
> > Reddy
> > (tireddy)
> > Envoyé : mercredi 23 mars 2016 03:45
> > À : Roland Dobbins; dots
> > Objet : Re: [Dots] requirements clarifications needed
> >
> > > -----Original Message-----
> > > From: Dots [mailto:[email-masked]] On Behalf Of Roland
> > > Dobbins
> > > Sent: Monday, March 21, 2016 10:11 PM
> > > To: dots
> > > Subject: Re: [Dots] requirements clarifications needed
> > >
> > > On 20 Mar 2016, at 21:44, Andrew Mortensen wrote:
> > > > 3. Whether reduced fate sharing warrants a requirement, as raised
> > > > in [3].
> > >
> > > Avoidance of fate-sharing should be an operational recommendation,
> > > and the protocol itself and messaging should lend themselves to such
> > > to the degree that it is practicable, IMHO.
> >
> > Why would the DOTS agents IP addresses/ports change during the attack ?
> > Though there is binding to a 5-tuple, (D)TLS allows session resumption.
> >
> > >
> > > > 4. Whether a DOTS server SHOULD be able to redirect a DOTS client
> > > > to another DOTS server [4].
> > >
> > > Yes, given proper bidirectional authentication, IMHO.
> >
> > Redirecting the DOTS client to another DOTS server should be avoided
> > during attack time, re-direction may incur multiple roundtrips before
> > DOTS signal can be conveyed to the DOTS server.
> > How does the old DOTS server ensure that the new DOTS server to which
> > the client is re-directed does not further re-direct the client (avoid
> > endlessly re-directing the DOTS client) ?
> >
> > -Tiru
> >
> > >
> > > -----------------------------------
> > > Roland Dobbins <[email-masked]>
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/dots
> > _______________________________________________
> > Dots mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dots