Subject: Re: [Dots] requirements clarifications needed

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 16:52:07 +0000

> -----Original Message-----
> From: Robert Moskowitz [mailto:[email-masked]]
> Sent: Wednesday, March 23, 2016 9:05 AM
> To: Tirumaleswar Reddy (tireddy); Roland Dobbins; dots
> Subject: Re: [Dots] requirements clarifications needed
> 
> 
> 
> On 03/22/2016 10:45 PM, Tirumaleswar Reddy (tireddy) wrote:
> >> -----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.
> 
> A mobile target, though how such a one can be targetted is interesting.
> The attack would have to be against a whole range of addresses.  Or more
> likely a cable connection that due to the attack bounces and assigns a new
> address.  That makes more sense.  Perhaps the cable ISPs can add here.
> 
> >
> >>> 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) ?
> 
> And as I said to you and Andy, how is the security state maintained?  Is
> it duplicated ahead of this event?  Does a new security state need to be
> negotiated at a time where such a negotiation is likely to fail?  So I
> also wonder how this works.

Re-direction to another DOTS server in the same administrative domain is straight forward, (D)TLS session resumption https://tools.ietf.org/html/rfc5077 will solve the problem. Re-direction to a DOTS server in another administrative domain needs more thought (e.g. use OAuth to authorize the DOTS client to use the new DOTS server).

-Tiru

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 23 Mar 2016 16:57:27 +0000

>Re-direction to another DOTS server in the same administrative domain is straight forward, (D)TLS session resumption https://tools.ietf.org/html/rfc5077 will solve the problem. Re-direction to a DOT…

I can see the case for redirection within the same administrative domain (for any number of reasons).  

Redirection between domains would seem to me to be better handled by a DOTS relay.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 17:29:38 +0000

> From: Teague, Nik [mailto:[email-masked]]
> Sent: Wednesday, March 23, 2016 10:27 PM
> To: Tirumaleswar Reddy (tireddy); Robert Moskowitz; Roland Dobbins; dots
> On 23/03/2016 16:52, "Dots on behalf of Tirumaleswar Reddy (tireddy)"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> 
> >>>
> >>>>> 4. Whether a DOTS server SHOULD be able to redirect a DOTS client
> >>>>> to another DOTS server [4].
> >>during attack time, re-direction may incur multiple roundtrips before
> >>DOTS signal can be conveyed to the DOTS server.
> >>And as I said to you and Andy, how is the security state maintained?
> >>Is it duplicated ahead of this event?  Does a new security state need
> >>to be negotiated at a time where such a negotiation is likely to fail?
> >>So I also wonder how this works.
> >
> >Re-direction to another DOTS server in the same administrative domain is
> straight forward, (D)TLS session resumption
> https://tools.ietf.org/html/rfc5077 will solve the problem. Re-direction to a
> DOTS server in another administrative domain needs more thought (e.g. use
> OAuth to authorize the DOTS client to use the new DOTS server).
> 

Can you please clarify how re-direction will be performed by the DOTS relay, don't see DOTS relay used in Recursive Signaling for re-direction https://tools.ietf.org/html/draft-mortensen-dots-architecture-00#section-4.2.4.

-Tiru

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 23 Mar 2016 17:34:37 +0000

>Can you please clarify how re-direction will be performed by the DOTS relay, don't see DOTS relay used in Recursive Signaling for re-direction https://tools.ietf.org/html/draft-mortensen-dots-archit…

My text wasn’t clear.

I meant that rather than redirecting between domains - relaying between domains would be a more suitable proposition.