Subject: [Dots] Signal Channel - 300 Redirected Signaling

From: "Jon Shallow" <[email-masked]>
Date: Wed, 4 Apr 2018 14:31:04 +0100

Hi there,

I have implemented the 300 Redirected-Signal in my DOTS code.  This then
raises some questions about usability.

Usability #1

Architecture 3.2.2 Redirected Signalling

   4.  Having redirected the DOTS client, DOTS server A ceases sending
       server signals.  The DOTS client likewise stops sending client
       signals to DOTS server A.  DOTS session 1 is terminated.

Clearly indicates that the original session (Client to Server A) is no more
once redirected and only Client to Server B is in use.

How is the traffic redirected back to Server A once maintenance /
overloading etc. has finished?  My assumption is that Server B sends a
redirect to go back to Server A as Server A has no way to say over a now
non-existent session to say "come back".

Do we need to keep the existing Client to Server A session warm (or perhaps
to probe periodically) to see if Server A is capable of handling the Client
again by a server response extension to the protocol (e.g. a 3.01)

Should there be a retry period parameter added in to the 3.00 protocol (as I
read it, ttl only refers to the IP address)?

Usability #2

Server A says "Redirect to Server B" due to overloading.  Server B accepts
things for a while and then is instructed/decides to redirect traffic back
to A.  Server A is left still overload configured to redirect to B.  How
should the client handle this as there is no suitable Server?

I agree that there needs to be co-ordination between Server A and Server B,
but user error may creep in.

Usability #3

Server A says "Redirect to Server B" as it going to be shut down because of
maintenance.  Server B accepts things for a while and then is instructed (in
probable user error) to redirect traffic back to A (perhaps because it has
hit an overload condition).  How should the client handle this?

Regards

Jon

---

From: <[email-masked]>
Date: Wed, 4 Apr 2018 14:07:09 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Jon Shallow
> Envoyé : mercredi 4 avril 2018 15:31
> À : [email-masked]
> Objet : [Dots] Signal Channel - 300 Redirected Signaling
> 
> Hi there,
> 

[Med] That's one possibility. This one does not require any update to the signal-channel specification.

Another approach would be to not require any redirect signal from server B. The client will remove server B's records upon the expiry of the TTL and will fall back to the "base" DOTS servers configuration that was provisioned to the client using DHCP or whatever mechanism. 

> again by a server response extension to the protocol (e.g. a 3.01)

[Med] Redirect was initially introduced to manage a server overload, so I don't think it makes sense to probe or maintain a session with server A. 

> read it, ttl only refers to the IP address)?

[Med] The client will automatically switch to Server A when all alternate records expire.  

> should the client handle this as there is no suitable Server?

[Med] This is a service configuration problem. We may ask:
* the client to log the error and notify the administrator.
* and/or stop the redirection after n cycles.

Still, this does not solve the problem. 

> hit an overload condition).  How should the client handle this?

[Med] Isn't this a sub-case or #2?

> 
> 
> Regards
> 
> Jon
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 4 Apr 2018 15:46:05 +0100

Hi there,

See inline [Jon]

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 04 April 2018 15:07
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 4 avril 2018 15:31 À : [email-masked] Objet : [Dots] 
> Signal Channel - 300 Redirected Signaling
> 
> Hi there,
> 
> I have implemented the 300 Redirected-Signal in my DOTS code.  This 
> then raises some questions about usability.
> 
> Usability #1
> 
> Clearly indicates that the original session (Client to Server A) is no 
> more once redirected and only Client to Server B is in use.
> 
> redirect to go back to Server A as Server A has no way to say over a 
> now non-existent session to say "come back".

[Med] That's one possibility. This one does not require any update to the
signal-channel specification.

Another approach would be to not require any redirect signal from server B.
The client will remove server B's records upon the expiry of the TTL and
will fall back to the "base" DOTS servers configuration that was provisioned
to the client using DHCP or whatever mechanism. 
[Jon]  OK.  The TTL is defined at, associated with the IP address level
under alt-server-record, not under
ietf-dots-signal-channel:redirected-signal.   The ttl definition is
ambiguous as to what it refers to and perhaps could be tightened up in the
language (I read it as being associated with "addr" in the sense of a DNS
TTL).

> 
> Do we need to keep the existing Client to Server A session warm (or 
> perhaps to probe periodically) to see if Server A is capable of 
> handling the Client again by a server response extension to the 
> protocol (e.g. a 3.01)

[Med] Redirect was initially introduced to manage a server overload, so I
don't think it makes sense to probe or maintain a session with server A. 
[Jon] Agreed, but I needed to raise the question.

> 
> Should there be a retry period parameter added in to the 3.00 protocol 
> (as I read it, ttl only refers to the IP address)?

[Med] The client will automatically switch to Server A when all alternate
records expire. 
[Jon] OK - again the 4.6 text needs to get tightened up to reflect this as
the intent.

> 
> Usability #2
> 
> Server A says "Redirect to Server B" due to overloading.  Server B 
> accepts things for a while and then is instructed/decides to redirect 
> traffic back to A.  Server A is left still overload configured to 
> redirect to B.  How should the client handle this as there is no suitable
Server?

Still, this does not solve the problem. 
[Jon] Agreed there is a problem here

> 
> I agree that there needs to be co-ordination between Server A and 
> Server B, but user error may creep in.
> 
> Usability #3
> 
> Server A says "Redirect to Server B" as it going to be shut down 
> because of maintenance.  Server B accepts things for a while and then 
> is instructed (in probable user error) to redirect traffic back to A 
> (perhaps because it has hit an overload condition).  How should the client
handle this?

[Med] Isn't this a sub-case or #2?
[Jon] Yes, but I wanted to bring in Server A being alive and able to respond
versus Server A down and not responding due to maintenance.
[Jon] With my better understanding of TTL we still have an issue if the TTL
expires and Server A is having an extended outage.  How do we recover from
that? 
~jon

---

From: <[email-masked]>
Date: Wed, 4 Apr 2018 15:09:39 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : mercredi 4 avril 2018 16:46
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : RE: [Dots] Signal Channel - 300 Redirected Signaling
> 
> Hi there,
> 
> See inline [Jon]
> 
> Regards
> 
> Jon
> 

[Med] The current design for a finer granularity as it allows to associate the same or distinct TTL to addresses that are associated with the same record.

I can make this change:

OLD: 
   addr:  IP address of an alternate DOTS server.

   ttl:  Time to live (TTL) represented as an integer number of seconds.

NEW:
   ttl:  Time to live (TTL) of the alternate IP address, represented as
      an integer number of seconds.

   addr:  IP address of an alternate DOTS server.  A DOTS client MUST
      NOT use this IP address to contact its DOTS server upon expiry of
      the associated TTL.  If all alternate IP addresses have expired,
      the DOTS client MUST use the DOTS server(s) that was provisioned
      using means discussed in Section 4.1.

> [Jon] OK - again the 4.6 text needs to get tightened up to reflect this as

[Med] see above. 

> expires and Server A is having an extended outage.  How do we recover from

[Med] Exact. This is a service configuration problem, IMHO.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 4 Apr 2018 15:39:44 +0000

The TTL value returned under alt-server-record is equivalent to the DNS TTL value. A DDoS mitigation provider with multiple DOTS servers typically 
re-directs a DOTS client to a different DOTS server only if the alternate DOTS server has the capacity to handle the requests from the DOTS client.

We can add the following lines to avoid loops :

If the DOTS client has been redirected to a DOTS server to which it has already sent the mitigation request within the last five
minutes, it MUST ignore the redirection and try reaching others servers listed in the local configuration or discovered using dynamic means such as DHCP or SRV procedures. 
This prevents infinite ping-ponging between servers in case of redirection loops.

-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Wednesday, April 4, 2018 8:16 PM
> To: [email-masked]; [email-masked]
> The client will remove server B's records upon the expiry of the TTL and will fall
> back to the "base" DOTS servers configuration that was provisioned to the client
> using DHCP or whatever mechanism.
> [Jon]  OK.  The TTL is defined at, associated with the IP address level under alt-
> server-record, not under
> language (I read it as being associated with "addr" in the sense of a DNS TTL).
> 
> >
> [Med] Redirect was initially introduced to manage a server overload, so I don't
> think it makes sense to probe or maintain a session with server A.
> [Jon] OK - again the 4.6 text needs to get tightened up to reflect this as the
> intent.
> 
> 
> >
> > Usability #2
> >

---

From: <[email-masked]>
Date: Thu, 5 Apr 2018 07:20:28 +0000

Hi Tiru, 

Works for me.  

I updated the draft with the text additions that were discussed in this thread. The changes can be found at:   
https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/draft-ietf-dots-signal-channel.txt 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : mercredi 4 avril 2018 17:40
> À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
> The TTL value returned under alt-server-record is equivalent to the DNS TTL
> value. A DDoS mitigation provider with multiple DOTS servers typically
> re-directs a DOTS client to a different DOTS server only if the alternate
> DOTS server has the capacity to handle the requests from the DOTS client.
> 
> If the DOTS client has been redirected to a DOTS server to which it has
> already sent the mitigation request within the last five
> minutes, it MUST ignore the redirection and try reaching others servers
> listed in the local configuration or discovered using dynamic means such as
> DHCP or SRV procedures.
> will fall
> don't
> records
> > expire.
> the

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 5 Apr 2018 09:05:16 +0100

Hi Med,

Thanks for this refresh to 4.6 Redirected Signaling

Some comments

#1

   The DOTS server can return the error response code 3.00 in response
   to a PUT request from the DOTS client or convey the error response
   code 3.00 in a unidirectional notification response from the DOTS
   server.

Why is this limited to a PUT request and/or unidirectional notification
response?
- Surely, any response, unsolicited or otherwise can contain a 3.00
- If Observe is not in use, then any unsolicited notification response will
potentially get rejected by the coap library layer, so a DOTS Server cannot
signal maintenance outage other than by closing the session.
- I missed this the last review - sorry

#2

   If the DOTS client has been redirected to a DOTS server to which it
   has already sent the mitigation request within the last five (5)
   minutes, it MUST ignore the redirection and try to contact other DOTS

s/ has already sent the mitigation request/ has already communicated with/

#3

      A DOTS client MUST NOT use an alternate IP address to contact its
      DOTS server upon expiry of the associated TTL.

To remove ambiguity over the use of FQDN, this could read

      A DOTS client MUST NOT use an alternate IP address to contact its
      DOTS server upon expiry of the associated TTL.  Furthermore, a DOTS
      Client MUST NOT use the alt-server FQDN if all of the
alt-server-records
      have expired.

Or alternatively

   alt-server:  FQDN of an alternate DOTS server.

This could read

   alt-server:  FQDN of an alternate DOTS server.  This FQDN is not to be
used for looking up IP addresses to use, but is there for the SNI extension
(7.1.  (D)TLS Protocol Profile)

Regards

Jon
-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 05 April 2018 08:20
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling

Hi Tiru, 

Works for me.  

I updated the draft with the text additions that were discussed in this
thread. The changes can be found at:   
https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/draf
t-ietf-dots-signal-channel.txt 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy 
> [mailto:[email-masked]]
> À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet : RE: 
> [Dots] Signal Channel - 300 Redirected Signaling
> 
> The TTL value returned under alt-server-record is equivalent to the 
> DNS TTL value. A DDoS mitigation provider with multiple DOTS servers 
> typically re-directs a DOTS client to a different DOTS server only if 
> the alternate DOTS server has the capacity to handle the requests from the
DOTS client.
> If the DOTS client has been redirected to a DOTS server to which it 
> has already sent the mitigation request within the last five minutes, 
> it MUST ignore the redirection and try reaching others servers listed 
> in the local configuration or discovered using dynamic means such as 
> DHCP or SRV procedures.
> > > Envoyé : mercredi 4 avril 2018 15:31 À : [email-masked] Objet : 
> > > [Dots] Signal Channel - 300 Redirected Signaling
> > >
> > > Hi there,
> > >
> > > I have implemented the 300 Redirected-Signal in my DOTS code.  
> > > This then raises some questions about usability.
> > >
> > > Usability #1
> > >
> > > Clearly indicates that the original session (Client to Server A) 
> > > is no more once redirected and only Client to Server B is in use.
> > >
> > > overloading etc. has finished?  My assumption is that Server B 
> > > sends a redirect to go back to Server A as Server A has no way to 
> > > say over a now non-existent session to say "come back".
> >
> > back to the "base" DOTS servers configuration that was provisioned 
> > to the
> client
> > ambiguous as to what it refers to and perhaps could be tightened up 
> > in the language (I read it as being associated with "addr" in the 
> > sense of a DNS
> TTL).
> >
> > >
> > > Do we need to keep the existing Client to Server A session warm 
> > > (or perhaps to probe periodically) to see if Server A is capable 
> > > of handling the Client again by a server response extension to the 
> > > protocol (e.g. a 3.01)
> >
> > > Should there be a retry period parameter added in to the 3.00 
> > > protocol (as I read it, ttl only refers to the IP address)?
> >
> > > accepts things for a while and then is instructed/decides to 
> > > redirect traffic back to A.  Server A is left still overload 
> > > configured to redirect to B.  How should the client handle this as 
> > > there is no suitable
> > Server?
> >
> > > because of maintenance.  Server B accepts things for a while and 
> > > then is instructed (in probable user error) to redirect traffic 
> > > back to A (perhaps because it has hit an overload condition).  How 
> > > should the client
> > handle this?
> >
> > [Jon] With my better understanding of TTL we still have an issue if 
> > the TTL expires and Server A is having an extended outage.  How do 
> > we recover from that?
> > ~jon
> > >
> > >
> > > Regards
> > >
> > > Jon
> > >

---

From: <[email-masked]>
Date: Thu, 5 Apr 2018 08:50:02 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 5 avril 2018 10:05
> À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]

[Med] There is no restriction in the text: 

   If a DOTS server wants to redirect a DOTS client to an alternative
   DOTS server for a signal session, then the response code 3.00
   (alternate server) will be returned in the response to the DOTS
   client.

The text you quoted is about a case in which redirect is likely : " The DOTS server **can** return the error response code.."

> s/ has already sent the mitigation request/ has already communicated with/

[Med] Fixed.

>       Client MUST NOT use the alt-server FQDN if all of the

[Med] I can add this to remove ambiguity.

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 5 Apr 2018 10:00:20 +0100

Hi Med,

See inline [Jon]

Regards

Jon
-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 05 April 2018 09:50
To: Jon Shallow; Konda, Tirumaleswar Reddy; [email-masked]
Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling

Re-,

Please see inline. 

Cheers,
Med

> À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; 
> [email-masked] Objet : RE: [Dots] Signal Channel - 300 Redirected 
> Signaling
> 
> Hi Med,
> 
> Why is this limited to a PUT request and/or unidirectional 
> notification response?
> - If Observe is not in use, then any unsolicited notification response 
> will potentially get rejected by the coap library layer, so a DOTS 
> Server cannot signal maintenance outage other than by closing the session.

[Jon] Agreed this preceding paragraph is more generic (which is why I
possibly did not pick up on this), but then the para I quoted implies it is
restricted to a PUT request which is not the case.  Perhaps
s/in response to a PUT request from/in response to any request from/
which works for me.

The text you quoted is about a case in which redirect is likely : " The DOTS
server **can** return the error response code.."
[Jon] but implied (not a MUST I agree) that it cannot be done if it was a
GET request 

> s/ has already sent the mitigation request/ has already communicated 

[Med] Fixed.
[Jon] Thanks

[Jon} Please do
~jon

>    alt-server:  FQDN of an alternate DOTS server.  This FQDN is not to 
> be used for looking up IP addresses to use, but is there for the SNI 
> extension (7.1.  (D)TLS Protocol Profile)
> 
> 
> Regards
> 
> Jon
> I updated the draft with the text additions that were discussed in 
> this thread. The changes can be found at:
> > Envoyé : mercredi 4 avril 2018 17:40 À : Jon Shallow; BOUCADAIR 
> > Mohamed IMT/OLN; [email-masked] Objet : RE:
> > typically re-directs a DOTS client to a different DOTS server only 
> > if the alternate DOTS server has the capacity to handle the requests 
> > from the
> DOTS client.
> >
> > has already sent the mitigation request within the last five 
> > minutes, it MUST ignore the redirection and try reaching others 
> > servers listed in the local configuration or discovered using 
> > dynamic means such as DHCP or SRV procedures.
> > > > De : Dots [mailto:[email-masked]] De la part de Jon 
> > > > Shallow Envoyé : mercredi 4 avril 2018 15:31 À : [email-masked]
Objet :
> > > > How is the traffic redirected back to Server A once maintenance 
> > > > / overloading etc. has finished?  My assumption is that Server B 
> > > > sends a redirect to go back to Server A as Server A has no way 
> > > > to say over a now non-existent session to say "come back".
> > >
> > > Another approach would be to not require any redirect signal from 
> > > server
> B.
> > > ambiguous as to what it refers to and perhaps could be tightened 
> > > up in the language (I read it as being associated with "addr" in 
> > > the sense of a DNS
> > TTL).
> > >
> > > >
> > > > of handling the Client again by a server response extension to 
> > > > the protocol (e.g. a 3.01)
> > >
> > > > Server A says "Redirect to Server B" due to overloading.  Server 
> > > > B accepts things for a while and then is instructed/decides to 
> > > > configured to redirect to B.  How should the client handle this 
> > > > as there is no suitable
> > > Server?
> > >
> > > > I agree that there needs to be co-ordination between Server A 
> > > > and Server B, but user error may creep in.
> > > >
> > > > Usability #3
> > > >
> > > > back to A (perhaps because it has hit an overload condition).  
> > > > How should the client
> > > handle this?
> > >
> > > [Jon] Yes, but I wanted to bring in Server A being alive and able 
> > > to
> > respond
> > > [Jon] With my better understanding of TTL we still have an issue 
> > > if the TTL expires and Server A is having an extended outage.  How 
> > > do we recover from that?
> > > ~jon
> > > >
> > > >
> > > > Regards
> > > >
> > > > Jon
> > > >

---

From: <[email-masked]>
Date: Thu, 5 Apr 2018 09:16:16 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 5 avril 2018 11:00

[Med] This is not what that text says. It only says that a typical usage is a response to PUT. This does not prevent a server to return for other requests. The example with PUT is more trivial compared to, for example GET/DELETE, which requires that the redirected server maintains the required information to process the request. 

Anyway, to avoid misinterpreting the text, I changed it to: 

   The DOTS server can return the error response code 3.00 in response
   to a request from the DOTS client or convey the error response code
   3.00 in a unidirectional notification response from the DOTS server.

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 5 Apr 2018 10:30:45 +0100

Hi Med,

See inline [Jon1]

Regards

Jon

> > - If Observe is not in use, then any unsolicited notification 
> > response will potentially get rejected by the coap library layer, so 
> > a DOTS Server cannot signal maintenance outage other than by closing the
session.
> possibly did not pick up on this), but then the para I quoted implies 
> it is restricted to a PUT request which is not the case.  Perhaps s/in 
> response to a PUT request from/in response to any request from/ which 
> works for me.
> 
> The text you quoted is about a case in which redirect is likely : " 
> The DOTS server **can** return the error response code.."
> [Jon] but implied (not a MUST I agree) that it cannot be done if it 
> was a GET request
> 

[Med] This is not what that text says. It only says that a typical usage is
a response to PUT. This does not prevent a server to return for other
requests. The example with PUT is more trivial compared to, for example
GET/DELETE, which requires that the redirected server maintains the required
information to process the request. 

[Jon1] I would not be expecting the redirected server to maintain state /
information, but would be expecting the DOTS client to treat the connection
to the redirected Server as if the DOTS client was just starting up and both
ends need to get synchronized (e.g. get Server's current mitigation state)
before retrying any GET / PUT etc. 

[Jon1] Thanks
~jon1

> >    alt-server:  FQDN of an alternate DOTS server.  This FQDN is not 
> > to be used for looking up IP addresses to use, but is there for the 
> > SNI extension (7.1.  (D)TLS Protocol Profile)
> >
> >
> > Regards
> >
> > Jon
> > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/mas
> > te
> > r/draf
> > > The TTL value returned under alt-server-record is equivalent to 
> > > the DNS TTL value. A DDoS mitigation provider with multiple DOTS 
> > > servers typically re-directs a DOTS client to a different DOTS 
> > > server only if the alternate DOTS server has the capacity to 
> > > handle the requests from the
> > DOTS client.
> > >
> > > If the DOTS client has been redirected to a DOTS server to which 
> > > it has already sent the mitigation request within the last five 
> > > > > Clearly indicates that the original session (Client to Server 
> > > > > A) is no more once redirected and only Client to Server B is in
use.
> > > > >
> > > > > How is the traffic redirected back to Server A once 
> > > > > maintenance / overloading etc. has finished?  My assumption is 
> > > > > that Server B sends a redirect to go back to Server A as 
> > > > > Server A has no way to say over a now non-existent session to say
"come back".
> > > > Another approach would be to not require any redirect signal 
> > > > from server
> > B.
> > > > back to the "base" DOTS servers configuration that was 
> > > > provisioned to the
> > > client
> > > > > Do we need to keep the existing Client to Server A session 
> > > > > warm (or perhaps to probe periodically) to see if Server A is 
> > > > > capable of handling the Client again by a server response 
> > > > > extension to the protocol (e.g. a 3.01)
> > > >
> > > > > Server A says "Redirect to Server B" due to overloading.  
> > > > > Server B accepts things for a while and then is 
> > > > > instructed/decides to redirect traffic back to A.  Server A is 
> > > > > left still overload configured to redirect to B.  How should 
> > > > > the client handle this as there is no suitable
> > > > Server?
> > > >
> > > > > Server A says "Redirect to Server B" as it going to be shut 
> > > > > down because of maintenance.  Server B accepts things for a 
> > > > > while and then is instructed (in probable user error) to 
> > > > > redirect traffic back to A (perhaps because it has hit an overload
condition).
> > > > [Jon] Yes, but I wanted to bring in Server A being alive and 
> > > > able to
> > > respond
> > > > if the TTL expires and Server A is having an extended outage.  
> > > > How do we recover from that?
> > > > ~jon
> > > > >
> > > > >
> > > > > Regards
> > > > >
> > > > > Jon
> > > > >

---

From: <[email-masked]>
Date: Thu, 5 Apr 2018 09:33:47 +0000

Re-,

ACKed. 

I guess that this one is closed.

Cheers,
Med

> Envoyé : jeudi 5 avril 2018 11:31

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 5 Apr 2018 10:45:22 +0100

Yes

-----Original Message-----
Sent: 05 April 2018 10:34

Re-,

ACKed. 

Cheers,
Med

> > > response will potentially get rejected by the coap library layer, 
> > > so a DOTS Server cannot signal maintenance outage other than by 
> > > closing the
> session.
> > [Jon] Agreed this preceding paragraph is more generic (which is why 
> > I possibly did not pick up on this), but then the para I quoted 
> > implies it is restricted to a PUT request which is not the case.  
> > Perhaps s/in response to a PUT request from/in response to any 
> > request from/ which works for me.
> >
> [Med] This is not what that text says. It only says that a typical 
> usage is a response to PUT. This does not prevent a server to return 
> for other requests. The example with PUT is more trivial compared to, 
> for example GET/DELETE, which requires that the redirected server 
> maintains the required information to process the request.
> 
> [Jon1] I would not be expecting the redirected server to maintain 
> state / information, but would be expecting the DOTS client to treat 
> the connection to the redirected Server as if the DOTS client was just 
> starting up and both ends need to get synchronized (e.g. get Server's 
> current mitigation state) before retrying any GET / PUT etc.
> 
> > >       DOTS server upon expiry of the associated TTL.  Furthermore, 
> > > a
> DOTS
> > >    alt-server:  FQDN of an alternate DOTS server.  This FQDN is 
> > > not to be used for looking up IP addresses to use, but is there 
> > > for the SNI extension (7.1.  (D)TLS Protocol Profile)
> > >
> > >
> > > Regards
> > >
> > > Jon
> > > > > >    4.  Having redirected the DOTS client, DOTS server A 
> > > > > > ceases
> > sending
> > > > > >        server signals.  The DOTS client likewise stops 
> > > > > > sending
> > client
> > > > > > maintenance / overloading etc. has finished?  My assumption 
> > > > > > is that Server B sends a redirect to go back to Server A as 
> > > > > ambiguous as to what it refers to and perhaps could be 
> > > > > tightened up in the language (I read it as being associated 
> > > > > with "addr" in the sense of a DNS
> > > > TTL).
> > > > >
> > > > > >
> > > > > > warm (or perhaps to probe periodically) to see if Server A 
> > > > > > is capable of handling the Client again by a server response 
> > > > > > Should there be a retry period parameter added in to the 
> > > > > > 3.00 protocol (as I read it, ttl only refers to the IP address)?
> > > > >
> > > > > > instructed/decides to redirect traffic back to A.  Server A 
> > > > > > is left still overload configured to redirect to B.  How 
> > > > > > I agree that there needs to be co-ordination between Server 
> > > > > > A and Server B, but user error may creep in.
> > > > > >
> > > > > > Usability #3
> > > > > >
> > > > > [Jon] With my better understanding of TTL we still have an 
> > > > > issue if the TTL expires and Server A is having an extended
outage.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 5 Apr 2018 10:06:21 +0000

> From: Jon Shallow [mailto:[email-masked]]
> Sent: Thursday, April 5, 2018 1:35 PM
> To: [email-masked]; Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]
> Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling
> 
> Hi Med,
> 
> Why is this limited to a PUT request and/or unidirectional notification response?
> potentially get rejected by the coap library layer, so a DOTS Server cannot signal
> maintenance outage other than by closing the session.

>       Client MUST NOT use the alt-server FQDN if all of the alt-server-records
>       have expired.
> 
> Or alternatively
> 
>    alt-server:  FQDN of an alternate DOTS server.  This FQDN is not to be used for
> looking up IP addresses to use, but is there for the SNI extension (7.1.  (D)TLS
> Protocol Profile)

I don't think the above restriction is correct for the following reasons: 

1) If the TTL value in the alt-server-record expires, DNS lookup can be performed by the DOTS client using the alternate DOTS server FQDN.
2) If the DNS server is reachable, the client may want to a DANE lookup to get the IP addresses and certificate to validate the alternate DOTS server certificate sent 
     in the DTLS handshake.

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 5 Apr 2018 11:17:20 +0100

See inline [Jon2]

Regards

Jon

-----Original Message-----
From: Konda, Tirumaleswar Reddy [mailto: [email-masked]]

Sent: 05 April 2018 11:06
To: Jon Shallow; [email-masked]; [email-masked]
Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling

response?

alt-server-records

1) If the TTL value in the alt-server-record expires, DNS lookup can be
performed by the DOTS client using the alternate DOTS server FQDN.
2) If the DNS server is reachable, the client may want to a DANE lookup to
get the IP addresses and certificate to validate the alternate DOTS server
certificate sent 
     in the DTLS handshake.

-Tiru
[Jon2] So, we are saying that TTL only refers to the IP addresses usage
before they expire and then we do a FQDN lookup, or can we try to do the
FQDN lookup immediately - and if that fails (DNS issues) then we can use the
IPs for the defined period of time. [I prefer to try the FQDN first].

[Jon2] Then we need a separate configurable usage lifetime entry for the
alt-server before the client retries the original server (needs to be more
than 5 minutes to handle ping--pong scenario).
~jon2

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 5 Apr 2018 11:01:51 +0000

> Sent: Thursday, April 5, 2018 3:47 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]; [email-masked]
> > notification
> 1) If the TTL value in the alt-server-record expires, DNS lookup can be performed
> by the DOTS client using the alternate DOTS server FQDN.
> 2) If the DNS server is reachable, the client may want to a DANE lookup to get
> the IP addresses and certificate to validate the alternate DOTS server certificate
> sent
>      in the DTLS handshake.
> 
> -Tiru
> [Jon2] So, we are saying that TTL only refers to the IP addresses usage before
> they expire and then we do a FQDN lookup, or can we try to do the FQDN
> lookup immediately - and if that fails (DNS issues) then we can use the IPs for the
> defined period of time. [I prefer to try the FQDN first].

Yes. 

> 
> [Jon2] Then we need a separate configurable usage lifetime entry for the alt-
> server before the client retries the original server (needs to be more than 5
> minutes to handle ping--pong scenario).

What is the problem if a separate configurable usage lifetime is not provided, and the client continues to use the alternate server ?

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Thu, 5 Apr 2018 11:20:08 +0000

Tiru, 

I don't see the NEW text as a restriction but as a simplification of the client's behavior. I don't want to over-specify the redirect behavior. 

Adding another yet layer of resolution will raise other issues such as the need to associate a TTL with the name itself. 

Cheers,
Med

> Envoyé : jeudi 5 avril 2018 12:06
> signal
> used for

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 6 Apr 2018 05:06:32 +0000

Hi Med,

The proposed update restricts the client no to do a DNS lookup using the alternate FQDN, further associating a TTL with the name complicates the functionality on the DOTS client to re-establish (D)TLS session with the primary DOTS server after the TTL expires.  My suggestion is to let the DOTS client continue to use the alternate DOTS server till it gets re-directed. I don't think the DOTS mitigation provider will know ahead-of-time the TTL value after which the DOTS client should disconnect communicating with the alternate DOTS server and re-establish 
(D)TLS session with the primary DOTS server. 

Cheers,
-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of
> Sent: Thursday, April 5, 2018 4:50 PM
> Jon Shallow <[email-masked]>; [email-masked]
> I don't see the NEW text as a restriction but as a simplification of the client's
> behavior. I don't want to over-specify the redirect behavior.
> 
> > > a DOTS Server cannot
> > > alt-server-
> > > to be
> > 1) If the TTL value in the alt-server-record expires, DNS lookup can
> > be performed by the DOTS client using the alternate DOTS server FQDN.
> > 2) If the DNS server is reachable, the client may want to a DANE
> > lookup to get the IP addresses and certificate to validate the
> > alternate DOTS server certificate sent
> >      in the DTLS handshake.
> >
> > -Tiru
> >
> > >
> > >
> > > Regards
> > >
> > > Jon
> > > > > > Shallow Envoyé : mercredi 4 avril 2018 15:31 À : [email-masked] Objet :
> > > > > > A) is no more once redirected and only Client to Server B is in use.
> > > > > >
> > > > > > redirect traffic back to A (perhaps because it has hit an
> > > > > > overload condition).  How should the client
> > > > > handle this?
> > > > >

---

From: <[email-masked]>
Date: Fri, 6 Apr 2018 05:56:11 +0000

Hi Tiru,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 6 avril 2018 07:07
> À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
> The proposed update restricts the client no to do a DNS lookup using the
> alternate FQDN, further associating a TTL with the name complicates the
> functionality on the DOTS client to re-establish (D)TLS session with the
> primary DOTS server after the TTL expires.  My suggestion is to let the DOTS
> client continue to use the alternate DOTS server till it gets re-directed.

[Med] This is possible with the current spec. 

Triggers for redirect and for falling back to the nominal configuration are deployment-specific. The current spec allows for almost all the cases discussed so far:

(1) Redirect for the request in progress: A server does so by returning TTL=0.
(2) The alternate server is not involved in fall back to the nominal server: upon expiry of ttl of all alternate IP addresses, then fall back automatically to the nominal server. 
(3) Redirect to an alternate server, which in turn will instruct the client to redirect to the "base" configuration:  a TTL is provided and the alternate server can reply with a redirect code any time before the expiry of the TTL. A long TTL can be returned if the alternate server will be responsible for coordinating fall back to the base server.  
(4) Stop infinite redirects

 I
> don't think the DOTS mitigation provider will know ahead-of-time the TTL
> value after which the DOTS client should disconnect communicating with the
> alternate DOTS server and re-establish

[Med] It depends on the nature of the redirect: overload, planned maintenance, etc. For planned maintenance, the TTL is known in general.  

> > Adding another yet layer of resolution will raise other issues such as the
> need to
> > associate a TTL with the name itself.
> >
> > Cheers,
> > Med
> >
> > > > looking up IP addresses to use, but is there for the SNI extension
> (7.1.
> > > (D)TLS
> > > > Protocol Profile)
> > >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 6 Apr 2018 09:58:52 +0000

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, April 6, 2018 11:26 AM
> > À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked] Objet : RE:
> > The proposed update restricts the client no to do a DNS lookup using
> > the alternate FQDN, further associating a TTL with the name
> > complicates the functionality on the DOTS client to re-establish
> > (D)TLS session with the primary DOTS server after the TTL expires.  My
> > suggestion is to let the DOTS client continue to use the alternate DOTS server
> till it gets re-directed.
> 
> Triggers for redirect and for falling back to the nominal configuration are
> deployment-specific. The current spec allows for almost all the cases discussed
> so far:
> 
> (2) The alternate server is not involved in fall back to the nominal server: upon
> expiry of ttl of all alternate IP addresses, then fall back automatically to the
> nominal server.
> (3) Redirect to an alternate server, which in turn will instruct the client to
> redirect to the "base" configuration:  a TTL is provided and the alternate server
> can reply with a redirect code any time before the expiry of the TTL. A long TTL
> can be returned if the alternate server will be responsible for coordinating fall
> back to the base server.

Yes, but (1) and (2) complicate the functionality of the DOTS client.  The only reason for adding alt-server-record in the response is DNS server may not be reachable by the DOTS server 
because of a DDoS attack.

> 
> 
>  I
> > don't think the DOTS mitigation provider will know ahead-of-time the
> > TTL value after which the DOTS client should disconnect communicating
> > with the alternate DOTS server and re-establish (D)TLS session with
> > the primary DOTS server.
> 
> [Med] It depends on the nature of the redirect: overload, planned maintenance,
> etc. For planned maintenance, the TTL is known in general.

It's the primary DOTS server responsibility to point the DOTS client to an optimal alternate server, where the client can continue to send migration requests without a frequent ping-pong between servers. 
I have seen TURN servers being deployed for several years with re-direction but without the need for TTL (see ALTERNATE-SERVER in https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) 

-Tiru

> > > I don't see the NEW text as a restriction but as a simplification of
> > > the
> > client's
> > > > > response will potentially get rejected by the coap library
> > > > > layer, so a DOTS Server cannot
> > > > signal
> > > > > Furthermore, a
> > > > > not to be
> > > > 1) If the TTL value in the alt-server-record expires, DNS lookup
> > > > can be performed by the DOTS client using the alternate DOTS server FQDN.
> > > > > I updated the draft with the text additions that were discussed
> > > > > in this thread. The changes can be found at:
> > > > > > Envoyé : mercredi 4 avril 2018 17:40 À : Jon Shallow;
> > > > > > BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet : RE:
> > > > > > The TTL value returned under alt-server-record is equivalent
> > > > > > to the DNS TTL value. A DDoS mitigation provider with multiple
> > > > > > DOTS servers typically re-directs a DOTS client to a different
> > > > > > DOTS server only if the alternate DOTS server has the capacity
> > > > > > to handle the requests from the
> > > > > DOTS client.
> > > > > >
> > > > > > If the DOTS client has been redirected to a DOTS server to
> > > > > > which it has already sent the mitigation request within the
> > > > > > last five minutes, it MUST ignore the redirection and try
> > > > > > reaching others servers listed in the local configuration or
> > > > > > discovered using dynamic means such as DHCP or SRV procedures.
> > > > > > > > -----Message d'origine----- De : Dots
> > > > > > > > [mailto:[email-masked]] De la part de Jon Shallow
> > > > > > > > maintenance / overloading etc. has finished?  My
> > > > > > > > assumption is that Server B sends a redirect to go back to
> > > > > > > > Server A as Server A has no way to say over a now
> > > > > > > > is capable of handling the Client again by a server
> > > > > > > > response extension to the protocol (e.g. a 3.01)
> > > > > > >
> > > > > > > > instructed/decides to redirect traffic back to A.  Server
> > > > > > > > A is left still overload configured to redirect to B.  How
> > > > > > > > I agree that there needs to be co-ordination between
> > > > > > > > Server A and Server B, but user error may creep in.
> > > > > > > >
> > > > > > > > Usability #3
> > > > > > > >
> > > > > > > > Server A says "Redirect to Server B" as it going to be
> > > > > > > > shut down because of maintenance.  Server B accepts things
> > > > > > > > for a while and then is instructed (in probable user
> > > > > > > > error) to redirect traffic back to A (perhaps because it
> > > > > > > > has hit an overload condition).  How should the client
> > > > > > > handle this?
> > > > > > >
> > > > > > > issue if the TTL expires and Server A is having an extended outage.

---

From: <[email-masked]>
Date: Fri, 6 Apr 2018 12:07:22 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
> Reddy
> Envoyé : vendredi 6 avril 2018 11:59
> Objet : Re: [Dots] Signal Channel - 300 Redirected Signaling
> 
> Yes, but (1) and (2) complicate the functionality of the DOTS client.

[Med] (1) and (2) is exactly the same functionality required for caching DNS replies.

  The
> only reason for adding alt-server-record in the response is DNS server may
> not be reachable by the DOTS server

[Med] Yes. Note that even if the name resolution was allowed, the client has to deal with the TTL indicated in the response...which is exactly the same as (1) and (2).
 
> It's the primary DOTS server responsibility to point the DOTS client to an
> optimal alternate server, where the client can continue to send migration
> requests without a frequent ping-pong between servers.

[Med] Agree. This is a service configuration problem. 

> I have seen TURN servers being deployed for several years with re-direction
> but without the need for TTL (see ALTERNATE-SERVER in
> https://tools.ietf.org/html/draft-ietf-tram-turnbis-11)
> 
> -Tiru
> 
> >
> > >
> > > Cheers,
> > > -Tiru
> > >
> it

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 6 Apr 2018 14:32:37 +0100

Excellent.

Thanks

Jon

-----Original Message-----
From: [email-masked] [mailto: [email-masked]] 
Sent: 06 April 2018 14:29
To: Jon Shallow; Konda, Tirumaleswar Reddy; [email-masked]
Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling

Hi Jon, all, 

I'm fine to put ttl at the level of alt-server.

Cheers,
Med

> Envoyé : vendredi 6 avril 2018 14:57
> À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked] 
> See inline [Jon3]
> > > > Envoyé : vendredi 6 avril 2018 07:07 À : BOUCADAIR Mohamed 
> > > > IMT/OLN; Jon Shallow; [email-masked] Objet : RE:
> > > > The proposed update restricts the client no to do a DNS lookup 
> > > > using the alternate FQDN, further associating a TTL with the 
> > > > name complicates the functionality on the DOTS client to 
> > > > re-establish (D)TLS session with the primary DOTS server after the
TTL expires.
> > > > My suggestion is to let the DOTS client continue to use the 
> > > > alternate DOTS
> > server
> > > Triggers for redirect and for falling back to the nominal 
> > > configuration are deployment-specific. The current spec allows for 
> > > almost all the cases
> > discussed
> > > so far:
> > >
> > > (1) Redirect for the request in progress: A server does so by 
> > > returning
> > TTL=0.
> > > (2) The alternate server is not involved in fall back to the 
> > > nominal
> > server: upon
> > > expiry of ttl of all alternate IP addresses, then fall back 
> > > automatically
> > to the
> > > nominal server.
> > > (3) Redirect to an alternate server, which in turn will instruct 
> > > the client
> > to
> > > redirect to the "base" configuration:  a TTL is provided and the 
> > > alternate
> > server
> > > can reply with a redirect code any time before the expiry of the 
> > > TTL. A
> > long TTL
> > only reason for adding alt-server-record in the response is DNS 
> > server may not be reachable by the DOTS server because of a DDoS attack.
> >
> 
> [Med] Yes. Note that even if the name resolution was allowed, the 
> client has to deal with the TTL indicated in the response...which is 
> exactly the same as (1) and (2).
> 
> 
> [Jon3] I think where I am struggling here is the overloaded use of TTL 
> - The TTL as per a DNS record and held as a part of alt-server-record 
> and then the TTL after which that the alt-server should be handling 
> the traffic before handling back to the original primary server.  It 
> either has to be one or the other, or they have to have different names.
> [Jon3] If we are only going to go for one variant for simplicity, then 
> I would prefer that it should be at the level of "alt-server".  
> Handling the TTL for DNS refresh is normally handled by a resolver 
> library, updated by the DNS packets coming in - unusual for an application
to have to do that.
> 
> > >
> > >
> > >  I
> > > > don't think the DOTS mitigation provider will know ahead-of-time 
> > > > the TTL value after which the DOTS client should disconnect 
> > > > communicating with the alternate DOTS server and re-establish 
> > It's the primary DOTS server responsibility to point the DOTS client 
> > to an optimal alternate server, where the client can continue to 
> > send migration requests without a frequent ping-pong between servers.
> 
> [Jon3] Agreed - and the 5 minute minimum ping-pong time is a good 
> safety net.
> ~jon3
> 
> > > > > I don't see the NEW text as a restriction but as a 
> > > > > simplification of the
> > > > client's
> > > > > > Envoyé : jeudi 5 avril 2018 12:06 À : Jon Shallow; BOUCADAIR 
> > > > > > > To: [email-masked]; Konda, Tirumaleswar 
> > > > > > > Reddy <[email-masked]>; [email-masked]
> > > > > > >    The DOTS server can return the error response code 3.00 
> > > > > > > in
> > response
> > > > > > >    to a PUT request from the DOTS client or convey the 
> > > > > > > error
> > response
> > > > > > >    code 3.00 in a unidirectional notification response 
> > > > > > > from the
> > DOTS
> > > > > > >    server.
> > > > > > >
> > > > > > > - Surely, any response, unsolicited or otherwise can 
> > > > > > > contain a
> > > > > > > 3.00
> > > > > > > - If Observe is not in use, then any unsolicited 
> > > > > > > notification response will potentially get rejected by the 
> > > > > > > coap library layer, so a DOTS Server cannot
> > > > > > signal
> which
> (5)
> > > > > > >       A DOTS client MUST NOT use an alternate IP address 
> > > > > > > to
> contact
> > its
> > > > > > >       A DOTS client MUST NOT use an alternate IP address 
> > > > > > > to
> contact
> > its
> > > > > > I don't think the above restriction is correct for the 
> > > > > > following
> > reasons:
> > > > > >
> > > > > > 1) If the TTL value in the alt-server-record expires, DNS 
> > > > > > lookup can be performed by the DOTS client using the 
> > > > > > alternate DOTS
> server
> > FQDN.
> > > > > > 2) If the DNS server is reachable, the client may want to a 
> > > > > > DANE lookup to get the IP addresses and certificate to 
> > > > > > validate the alternate DOTS server certificate sent
> > > > > >      in the DTLS handshake.
> > > > > >
> > > > > > -Tiru
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > Jon
> > > > > > > I updated the draft with the text additions that were 
> > > > > > > discussed in this thread. The changes can be found at:
> > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar 
> > > > > > > > Reddy [mailto:[email-masked]]
> > > > > > > > The TTL value returned under alt-server-record is 
> > > > > > > > equivalent to the DNS TTL value. A DDoS mitigation 
> > > > > > > > provider with multiple DOTS servers typically re-directs 
> > > > > > > > a DOTS client to a different DOTS server only if the 
> > > > > > > > alternate DOTS server has the capacity to handle the 
> > > > > > > > requests from the
> > > > > > > DOTS client.
> > > > > > > >
> > > > > > > > If the DOTS client has been redirected to a DOTS server 
> > > > > > > > to which it has already sent the mitigation request 
> > > > > > > > within the last five minutes, it MUST ignore the 
> > > > > > > > redirection and try reaching others servers listed in 
> > > > > > > > the local configuration or discovered using dynamic means
such as DHCP or SRV procedures.
> > > > > > > > > Jon Shallow
> > > > > > > > > From: Dots [mailto: [email-masked]] On Behalf 
> > > > > > > > > Of [email-masked]
> > > > > > > > > > [mailto:[email-masked]] De la part de Jon 
> > > > > > > > > > I have implemented the 300 Redirected-Signal in my 
> > > > > > > > > > DOTS
> code.
> > > > > > > > > >    4.  Having redirected the DOTS client, DOTS 
> > > > > > > > > > server A ceases
> > > > > > sending
> > > > > > > > > >        server signals.  The DOTS client likewise 
> > > > > > > > > > stops sending
> > > > client
> > > > > > > > > > assumption is that Server B sends a redirect to go 
> > > > > > > > > > back to Server A as Server A has no way to say over 
> > > > > > > > > > a now non-existent session to say
> > > > > "come back".
> > > > > > > > >
> > > > > > > > > Another approach would be to not require any redirect 
> > > > > > > > > signal from server
> > > > > > > B.
> > > > > > > > > tightened up in the language (I read it as being 
> > > > > > > > > associated with "addr" in the sense of a DNS
> > > > > > > > TTL).
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Do we need to keep the existing Client to Server A 
> > > > > > > > > > session warm (or perhaps to probe periodically) to 
> > > > > > > > > > see if Server A is capable of handling the Client 
> > > > > > > > > think it makes sense to probe or maintain a session 
> > > > > > > > > with
> server
> > A.
> > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to the 
> > > > > > > > > > IP
> > address)?
> > > > > > > > >
> > > > > > > > > > instructed/decides to redirect traffic back to A.  
> > > > > > > > > > Server A is left still overload configured to 
> > > > > > > > > > Server A says "Redirect to Server B" as it going to 
> > > > > > > > > > be shut down because of maintenance.  Server B 
> > > > > > > > > > accepts things for a while and then is instructed 
> > > > > > > > > > (in probable user
> > > > > > > > > > error) to redirect traffic back to A (perhaps 
> > > > > > > > > > because it has hit an overload condition).  How 
> > > > > > > > > > should the client
> > > > > > > > > handle this?
> > > > > > > > >
> > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being 
> > > > > > > > > alive and able to
> > > > > > > > respond
> > > > > > > > > [Jon] With my better understanding of TTL we still 
> > > > > > > > > have an issue if the TTL expires and Server A is 
> > > > > > > > > having an extended
> > outage.

---

From: <[email-masked]>
Date: Fri, 6 Apr 2018 14:20:45 +0000

FWIW, I implemented the change at: https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/draft-ietf-dots-signal-channel.txt 

Cheers,
Med 

> Envoyé : vendredi 6 avril 2018 15:33

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 6 Apr 2018 15:36:05 +0100

Hi Med,

Thanks for this.  I would like to see the ttl: definition tightened up
(moved away from the DNS TTL version)

Old

   ttl:  Time to live (TTL) of alternate records, represented as an
      integer number of seconds.  That is, the time interval that
      alternate IP addresses may be cached by a DOTS client.

      '0' means that an alternate IP address is only to be used for the
      request in progress, and consequently that IP address should not
      be cached.

      If no 'ttl' is returned in a redirect response, this is equivalent
      to returning a 'ttl' parameter set to '0'.

      If 'alt-server-record' has expired, the DOTS client MUST use the
      DOTS server(s) that was provisioned using means discussed in
      Section 4.1.  Furthermore, a DOTS client MUST NOT use the alt-
      server FQDN if the 'alt-server-records' has expired.

New

   ttl:  Time to live (TTL) of the alternate DOTS server, represented as an
      integer number of seconds.  That is, the time interval that
      the alternate DOTS server may be cached for use by a DOTS client.

      '0' means that the alternate DOTS server is only to be used for the
      request in progress, and consequently the alternate DOTS server entry
should not
      be cached.

      If no 'ttl' is returned in a redirect response, this is equivalent
      to returning a 'ttl' parameter set to '0'.

      If the alternate DOTS server TTL has expired, the DOTS client MUST use
the
      DOTS server(s) that was provisioned using means discussed in
      Section 4.1.  

Regards

Jon

-----Original Message-----
Sent: 06 April 2018 15:21

FWIW, I implemented the change at:
https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/draf
t-ietf-dots-signal-channel.txt 

Cheers,
Med 

> > Envoyé : vendredi 6 avril 2018 14:57 À : BOUCADAIR Mohamed IMT/OLN; 
> > Konda, Tirumaleswar Reddy; [email-masked] Objet : RE: [Dots] Signal 
> > Channel - 300 Redirected Signaling
> >
> > Hi there,
> >
> > See inline [Jon3]
> >
> > Regards
> >
> > Jon
> >
> >
> > > > configuration are deployment-specific. The current spec allows 
> > > > for almost all the cases
> > > discussed
> > > > so far:
> > > >
> > - The TTL as per a DNS record and held as a part of 
> > alt-server-record and then the TTL after which that the alt-server 
> > should be handling the traffic before handling back to the original 
> > primary server.  It either has to be one or the other, or they have to
have different names.
> > [Jon3] If we are only going to go for one variant for simplicity, 
> > then I would prefer that it should be at the level of "alt-server".
> > > > > don't think the DOTS mitigation provider will know 
> > > > > ahead-of-time the TTL value after which the DOTS client should 
> > > > > disconnect communicating with the alternate DOTS server and 
> > > > > re-establish (D)TLS session with the primary DOTS server.
> > > >
> > > > [Med] It depends on the nature of the redirect: overload, 
> > > > planned
> > > maintenance,
> > > It's the primary DOTS server responsibility to point the DOTS 
> > > client to an optimal alternate server, where the client can 
> > > continue to send migration requests without a frequent ping-pong
between servers.
> > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar Reddy 
> > > > > > > Envoyé : jeudi 5 avril 2018 12:06 À : Jon Shallow; 
> > > > > > > >    The DOTS server can return the error response code 
> > > > > > > > 3.00 in
> > > response
> > > > > > > > notification response will potentially get rejected by 
> > > > > > > > the coap library layer, so a DOTS Server cannot
> > > > > > > signal
> > > > > > > 2) If the DNS server is reachable, the client may want to 
> > > > > > > a DANE lookup to get the IP addresses and certificate to 
> > > > > > > > > provider with multiple DOTS servers typically 
> > > > > > > > > re-directs a DOTS client to a different DOTS server 
> > > > > > > > > only if the alternate DOTS server has the capacity to 
> > > > > > > > > If the DOTS client has been redirected to a DOTS 
> > > > > > > > > server to which it has already sent the mitigation 
> > > > > > > > > request within the last five minutes, it MUST ignore 
> > > > > > > > > the redirection and try reaching others servers listed 
> > > > > > > > > in the local configuration or discovered using dynamic 
> > > > > > > > > means
> > > > > > > > > > >        signals to DOTS server A.  DOTS session 1 
> > > > > > > > > > > is
> > > terminated.
> > > > > > > > > > >
> > > > > > > > > > > How is the traffic redirected back to Server A 
> > > > > > > > > > > once maintenance / overloading etc. has finished?  
> > > > > > > > > > > My assumption is that Server B sends a redirect to 
> > > > > > > > > > > go back to Server A as Server A has no way to say 
> > > > > > > > > > > over a now non-existent session to say
> > > > > > "come back".
> > > > > > > > > >
> > > > > > > > > > Another approach would be to not require any 
> > > > > > > > > > redirect signal from server
> > > > > > > > B.
> > > > > > > > > > back to the "base" DOTS servers configuration that 
> > > > > > > > > > was provisioned to the
> > > > > > > > > client
> > > > > > > > > > ambiguous as to what it refers to and perhaps could 
> > > > > > > > > > be tightened up in the language (I read it as being 
> > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to 
> > > > > > > > > > > the IP
> > > address)?
> > > > > > > > > >
> > > > > > > > > > > I agree that there needs to be co-ordination 
> > > > > > > > > > > between Server A and Server B, but user error may
creep in.
> > > > > > > > > > >
> > > > > > > > > > > Usability #3
> > > > > > > > > > >
> > > > > > > > > > > Server A says "Redirect to Server B" as it going 
> > > > > > > > > > > to be shut down because of maintenance.  Server B

---

From: <[email-masked]>
Date: Fri, 6 Apr 2018 14:43:57 +0000

Re-,

Happily.

You may check the github version. 

Cheers,
Med

> Envoyé : vendredi 6 avril 2018 16:36
> > > > > > > > > server to

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 6 Apr 2018 14:44:11 +0000

> Sent: Friday, April 6, 2018 5:37 PM
> > De : Dots [mailto:[email-masked]] De la part de Konda,
> > Tirumaleswar Reddy Envoyé : vendredi 6 avril 2018 11:59 À : BOUCADAIR
> > Mohamed IMT/OLN; Jon Shallow; [email-masked] Objet : Re: [Dots] Signal
> > > > using the alternate FQDN, further associating a TTL with the name
> > > > (D)TLS session with the primary DOTS server after the TTL expires.
> > > (3) Redirect to an alternate server, which in turn will instruct the
> > > client
> > to
> > only reason for adding alt-server-record in the response is DNS server
> > may not be reachable by the DOTS server because of a DDoS attack.
> >
> 
> [Med] Yes. Note that even if the name resolution was allowed, the client has to
> deal with the TTL indicated in the response...which is exactly the same as (1) and
> (2).

No, the TTL indicated in the alt-server-record is equivalent to the TTL value in the DNS response for caching. 

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 6 Apr 2018 14:55:22 +0000

The below proposed change does not look good to me, its causing the DOTS client to ping-pong between multiple DOTS servers because of the TTL value.  The alternate server should serve the DOTS client till there is a planned maintenance, if it is getting over-subscribed it should re-direct the new DOTS clients to an alternate server and avoid bouncing the existing DOTS clients which have been sending mitigation requests to it.  

-Tiru

> Sent: Friday, April 6, 2018 8:06 PM
> Thanks for this.  I would like to see the ttl: definition tightened up (moved away
> from the DNS TTL version)
> 
> Old
> 
>       request in progress, and consequently the alternate DOTS server entry should
> not
>       be cached.
> 
>       If the alternate DOTS server TTL has expired, the DOTS client MUST use the
> > > > > > > > > > > [Med] This is a service configuration problem. We
> > > > > > > > > > > may
> ask:

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 7 Apr 2018 14:27:42 +0100

Hi there,

My suggestion would be to make ttl of -1 'infinite', otherwise have a
minimum value of 300 seconds.  The text could read (including referring to
the optional etc. to be consistent with the rest of the document:-

   This is a required attribute.

   alt-server-record:  A list of IP addresses of an alternate DOTS
      server.

    This is an optional attribute.

   ttl:  Time to live (TTL) of the alternate DOTS server, represented as
      an integer number of seconds.  That is, the time interval that the
      alternate DOTS server may be used by a DOTS client.

      The minimum value is '300' seconds, or '-1'.

      '-1' means that the alternate DOTS server is to be used until the
alternate DOTS server redirects the traffic with another 3.00 response.
There is no TTL expiry.

      If no 'ttl' is returned in a redirect response, this is equivalent
      to returning a 'ttl' parameter set to '-1'.

      If the alternate DOTS server TTL has expired, the DOTS client MUST
      use the DOTS server(s) that was provisioned using means discussed
      in Section 4.1.  

    This is an optional attribute.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 06 April 2018 15:55
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling

The below proposed change does not look good to me, its causing the DOTS
client to ping-pong between multiple DOTS servers because of the TTL value.
The alternate server should serve the DOTS client till there is a planned
maintenance, if it is getting over-subscribed it should re-direct the new
DOTS clients to an alternate server and avoid bouncing the existing DOTS
clients which have been sending mitigation requests to it.  

-Tiru

>       request in progress, and consequently the alternate DOTS server 
> entry should not
>       be cached.
> 
> > Envoyé : vendredi 6 avril 2018 15:33 À : BOUCADAIR Mohamed IMT/OLN; 
> > Konda, Tirumaleswar Reddy; [email-masked] Objet : RE: [Dots] Signal 
> > > Envoyé : vendredi 6 avril 2018 14:57 À : BOUCADAIR Mohamed 
> > > IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked] Objet : RE: 
> > > > > > The proposed update restricts the client no to do a DNS 
> > > > > > lookup using the alternate FQDN, further associating a TTL 
> > > > > > with the name complicates the functionality on the DOTS 
> > > > > > client to re-establish (D)TLS session with the primary DOTS 
> > > > > > server after the
> > TTL expires.
> > > > > (3) Redirect to an alternate server, which in turn will 
> > > > > instruct the client
> > > > to
> > > > > redirect to the "base" configuration:  a TTL is provided and 
> > > > > the alternate
> > > > server
> > > > > can reply with a redirect code any time before the expiry of 
> > > > > the TTL. A
> > > > long TTL
> > > > > can be returned if the alternate server will be responsible 
> > > > > for
> > > > coordinating fall
> > > > > back to the base server.
> > > client has to deal with the TTL indicated in the response...which 
> > > is exactly the same as (1) and (2).
> > >
> > >
> > > should be handling the traffic before handling back to the 
> > > original primary server.  It either has to be one or the other, or 
> > > they have to
> have different names.
> > > > > > ahead-of-time the TTL value after which the DOTS client 
> > > > > > should disconnect communicating with the alternate DOTS 
> > > > > > server and re-establish (D)TLS session with the primary DOTS
server.
> > > > > > > > >       A DOTS client MUST NOT use an alternate IP 
> > > > > > > > > address to
> > > contact
> > > > its
> > > > > > > > >       A DOTS client MUST NOT use an alternate IP 
> > > > > > > > > address to
> > > contact
> > > > its
> > > > > > > > > This FQDN is not to be
> > > > > > > > 1) If the TTL value in the alt-server-record expires, 
> > > > > > > > DNS lookup can be performed by the DOTS client using the 
> > > > > > > > alternate DOTS
> > > server
> > > > FQDN.
> > > > > > > > 2) If the DNS server is reachable, the client may want 
> > > > > > > > to a DANE lookup to get the IP addresses and certificate 
> > > > > > > > to validate the alternate DOTS server certificate sent
> > > > > > > >      in the DTLS handshake.
> > > > > > > >
> > > > > > > > -Tiru
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > >
> > > > > > > > > Jon
> > > > > > > > > > Envoyé : mercredi 4 avril 2018 17:40 À : Jon 
> > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE:
> > > > > > > > > > only if the alternate DOTS server has the capacity 
> > > > > > > > > > the redirection and try reaching others servers 
> > > > > > > > > > listed in the local configuration or discovered 
> > > > > > > > > > using dynamic means
> > > > > > > > > > > From: Dots [mailto: [email-masked]] On 
> > > > > > > > > > > Behalf Of [email-masked]
> > > > > > > > > > > > I have implemented the 300 Redirected-Signal in 
> > > > > > > > > > > > my DOTS
> > > code.
> > > > > > > > > > > > My assumption is that Server B sends a redirect 
> > > > > > > > > > > > to go back to Server A as Server A has no way to 
> > > > > > > > > > > ambiguous as to what it refers to and perhaps 
> > > > > > > > > > > could be tightened up in the language (I read it 
> > > > > > > > > > > as being associated with "addr" in the sense of a 
> > > > > > > > > > > DNS
> > > > > > > > > > TTL).
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Do we need to keep the existing Client to Server 
> > > > > > > > > > > > A session warm (or perhaps to probe 
> > > > > > > > > > > > periodically) to see if Server A is capable of 
> > > > > > > > > > > > handling the Client again by a server response 
> > > > > > > > > > > think it makes sense to probe or maintain a 
> > > > > > > > > > > session with
> > > server
> > > > A.
> > > > > > > > > > > > to be shut down because of maintenance.  Server 
> > > > > > > > > > > > B accepts things for a while and then is 
> > > > > > > > > > > > instructed (in probable user
> > > > > > > > > > > > Dots mailing list [email-masked]

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Apr 2018 06:51:02 +0000

Hi Jon,

I partially agree with the suggested update.  A IP address is cached until the TTL value expires, the DOTS client need not disconnect existing sessions after the TTL expires, but after the TTL expires it must consider the IP address stale and not 
establish new (D)TLS sessions.

Cheers,
-Tiru

> Sent: Saturday, April 7, 2018 6:58 PM
> My suggestion would be to make ttl of -1 'infinite', otherwise have a minimum
> value of 300 seconds.  The text could read (including referring to the optional
> etc. to be consistent with the rest of the document:-
> 
>       '-1' means that the alternate DOTS server is to be used until the alternate
> DOTS server redirects the traffic with another 3.00 response.
> There is no TTL expiry.
> 
> maintenance, if it is getting over-subscribed it should re-direct the new DOTS
> clients to an alternate server and avoid bouncing the existing DOTS clients which
> have been sending mitigation requests to it.
> 
> -Tiru
> 
> an
> use the

---

From: <[email-masked]>
Date: Mon, 9 Apr 2018 07:44:58 +0000

Tiru, 

What about this update ones?

=======
   ttl:  Time to live (TTL) of the alternate DOTS server, represented as
      an integer number of seconds.  That is, the time interval that the
      alternate DOTS server may be cached for use by a DOTS client.

      A lifetime of negative one (-1) indicates indefinite TTL.  This
      value means that the alternate DOTS server is to be used until the
      alternate DOTS server redirects the traffic with another 3.00
      response.

      If the alternate DOTS server TTL has expired, the DOTS client MUST
      use the DOTS server(s), that was provisioned using means discussed
      in Section 4.1, for creating new requests.

===

Cheers,
Med

> Envoyé : lundi 9 avril 2018 08:51
> I partially agree with the suggested update.  A IP address is cached until
> the TTL value expires, the DOTS client need not disconnect existing sessions
> after the TTL expires, but after the TTL expires it must consider the IP
> address stale and not
> minimum

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Apr 2018 08:22:33 +0000

> Sent: Monday, April 9, 2018 1:15 PM

Above text looks good.

>       in Section 4.1, for creating new requests.

It looks too restrictive, typically the DNS TTL values are short-lived (e.g. few seconds) but the sessions are long-lived. 
Why not replace "for creating new requests" with "for creating new DOTS session" ?

--Tiru

> > I partially agree with the suggested update.  A IP address is cached
> > until the TTL value expires, the DOTS client need not disconnect
> > existing sessions after the TTL expires, but after the TTL expires it
> > must consider the IP address stale and not establish new (D)TLS
> > sessions.
> >
> > Cheers,
> > -Tiru
> >
> > > value of 300 seconds.  The text could read (including referring to
> > > the
> > optional
> > > From: Dots [mailto: [email-masked]] On Behalf Of Konda,
> > > Tirumaleswar Reddy
> > > The below proposed change does not look good to me, its causing the
> > > DOTS client to ping-pong between multiple DOTS servers because of the TTL
> value.
> > > The alternate server should serve the DOTS client till there is a
> > > planned maintenance, if it is getting over-subscribed it should
> > > re-direct the new
> > DOTS
> > > clients to an alternate server and avoid bouncing the existing DOTS
> > > clients
> > which
> > > > Thanks for this.  I would like to see the ttl: definition
> > > > tightened up (moved away from the DNS TTL version)
> > > >
> > > > Old
> > > >
> > > >       request in progress, and consequently the alternate DOTS
> > > > server entry should not
> > > >       be cached.
> > > >
> > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/m
> > > > aste
> > > > r/draf
> > > > > Envoyé : vendredi 6 avril 2018 15:33 À : BOUCADAIR Mohamed
> > > > > IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked] Objet : RE:
> > > > > > > > > Envoyé : vendredi 6 avril 2018 07:07 À : BOUCADAIR
> > > > > > > > > Mohamed IMT/OLN; Jon Shallow; [email-masked] Objet : RE:
> > > > > > > > > lookup using the alternate FQDN, further associating a
> > > > > > > > > TTL with the name complicates the functionality on the
> > > > > > > > > DOTS client to re-establish (D)TLS session with the
> > > > > > > > > primary DOTS server after the
> > > > > TTL expires.
> > > > > > > > > My suggestion is to let the DOTS client continue to use
> > > > > > > > > the alternate DOTS
> > > > > > > server
> > > > > > > > configuration are deployment-specific. The current spec
> > > > > > > > allows for almost all the cases
> > > > > > > discussed
> > > > > > > > so far:
> > > > > > > >
> > > > > > > > (1) Redirect for the request in progress: A server does so
> > > > > > > > by returning
> > > > > > > TTL=0.
> > > > > > > > (2) The alternate server is not involved in fall back to
> > > > > > > > the nominal
> > > > > > > server: upon
> > > > > > > > expiry of ttl of all alternate IP addresses, then fall
> > > > > > > > back automatically
> > > > > > > to the
> > > > > > > > nominal server.
> > > > > > > > redirect to the "base" configuration:  a TTL is provided
> > > > > > > > and the alternate
> > > > > > > server
> > > > > > > > can reply with a redirect code any time before the expiry
> > > > > > > > of the TTL. A
> > > > > > > long TTL
> > > > > > > > can be returned if the alternate server will be
> > > > > > > > responsible for
> > > > > > > coordinating fall
> > > > > > > > back to the base server.
> > > > > > > Yes, but (1) and (2) complicate the functionality of the
> > > > > > > DOTS
> > > client.
> > > > > >
> > > > > > > only reason for adding alt-server-record in the response is
> > > > > > > DNS server may not be reachable by the DOTS server because
> > > > > > > of a DDoS
> > > > attack.
> > > > > > >
> > > > > >
> > > > > > [Med] Yes. Note that even if the name resolution was allowed,
> > > > > > the client has to deal with the TTL indicated in the
> > > > > > response...which is exactly the same as (1) and (2).
> > > > > >
> > > > > >
> > > > > > alt-server-record and then the TTL after which that the
> > > > > > alt-server should be handling the traffic before handling back
> > > > > > to the original primary server.  It either has to be one or
> > > > > > the other, or they have to
> > > > have different names.
> > > > > > [Jon3] If we are only going to go for one variant for
> > > > > > simplicity, then I would prefer that it should be at the level of "alt-
> server".
> > > > > > Handling the TTL for DNS refresh is normally handled by a
> > > > > > resolver library, updated by the DNS packets coming in -
> > > > > > unusual for an application
> > > > > to have to do that.
> > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >  I
> > > > > > > It's the primary DOTS server responsibility to point the
> > > > > > > DOTS client to an optimal alternate server, where the client
> > > > > > > can continue to send migration requests without a frequent
> > > > > > > ping-pong
> > > > between servers.
> > > > > >
> > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a
> > > > > > good safety net.
> > > > > > ~jon3
> > > > > >
> > > > > > > I have seen TURN servers being deployed for several years
> > > > > > > with
> > > > > > re-direction
> > > > > > > > > > > >    to a PUT request from the DOTS client or convey
> > > > > > > > > > > > the error
> > > > > > > response
> > > > > > > > > > > >    code 3.00 in a unidirectional notification
> > > > > > > > > > > > response from the
> > > > > > > DOTS
> > > > > > > > > > > >    server.
> > > > > > > > > > > >
> > > > > > > > > > > > - Surely, any response, unsolicited or otherwise
> > > > > > > > > > > > can contain a
> > > > > > > > > > > > 3.00
> > > > > > > > > > > > notification response will potentially get
> > > > > > > > > > > > rejected by the coap library layer, so a DOTS
> > > > > > > > > > > > Server cannot
> > > > > > > > > > > signal
> > > > > > > > > > > I don't think the above restriction is correct for
> > > > > > > > > > > the following
> > > > > > > reasons:
> > > > > > > > > > >
> > > > > > > > > > > 1) If the TTL value in the alt-server-record
> > > > > > > > > > > expires, DNS lookup can be performed by the DOTS
> > > > > > > > > > > client using the alternate DOTS
> > > > > > server
> > > > > > > FQDN.
> > > > > > > > > > > 2) If the DNS server is reachable, the client may
> > > > > > > > > > > want to a DANE lookup to get the IP addresses and
> > > > > > > > > > > certificate to validate the alternate DOTS server certificate
> sent
> > > > > > > > > > >      in the DTLS handshake.
> > > > > > > > > > >
> > > > > > > > > > > -Tiru
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Regards
> > > > > > > > > > > >
> > > > > > > > > > > > Jon
> > > > > > > > > > > > I updated the draft with the text additions that
> > > > > > > > > > > > were discussed in this thread. The changes can be found at:
> > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signa
> > > > > > > > > > > > l-
> > > > > > > > > > > channel/blob/master/draf
> > > > > > > > > > > > > The TTL value returned under alt-server-record
> > > > > > > > > > > > > is equivalent to the DNS TTL value. A DDoS
> > > > > > > > > > > > > mitigation provider with multiple DOTS servers
> > > > > > > > > > > > > typically re-directs a DOTS client to a
> > > > > > > > > > > > > different DOTS server only if the alternate DOTS
> > > > > > > > > > > > > server has the capacity to handle the requests
> > > > > > > > > > > > > from the
> > > > > > > > > > > > DOTS client.
> > > > > > > > > > > > >
> > > > > > > > > > > > > server to which it has already sent the
> > > > > > > > > > > > > mitigation request within the last five minutes,
> > > > > > > > > > > > > it MUST ignore the redirection and try reaching
> > > > > > > > > > > > > others servers listed in the local configuration
> > > > > > > > > > > > > or discovered using dynamic means
> > > > > > > > > > > > > > > [mailto:[email-masked]] De la part de
> > > > > > > > > > > > > > > Jon Shallow Envoyé : mercredi 4 avril 2018 15:31 À :
> > > > > > > > > > > > > > > [email-masked]
> > > > > > > > > Objet :
> > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal
> > > > > > > > > > > > > > > in my DOTS
> > > > > > code.
> > > > > > > > > > > > > > >    4.  Having redirected the DOTS client,
> > > > > > > > > > > > > > > DOTS server A ceases
> > > > > > > > > > > sending
> > > > > > > > > > > > > > >        server signals.  The DOTS client
> > > > > > > > > > > > > > > likewise stops sending
> > > > > > > > > client
> > > > > > > > > > > > > > >        signals to DOTS server A.  DOTS
> > > > > > > > > > > > > > > session 1 is
> > > > > > > terminated.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > How is the traffic redirected back to Server
> > > > > > > > > > > > > > > A once maintenance / overloading etc. has finished?
> > > > > > > > > > > > > > > My assumption is that Server B sends a
> > > > > > > > > > > > > > > redirect to go back to Server A as Server A
> > > > > > > > > > > > > > > has no way to say over a now non-existent
> > > > > > > > > > > > > > > session to say
> > > > > > > > > > "come back".
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > back to the "base" DOTS servers configuration
> > > > > > > > > > > > > > that was provisioned to the
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > could be tightened up in the language (I read
> > > > > > > > > > > > > > it as being associated with "addr" in the
> > > > > > > > > > > > > > sense of a DNS
> > > > > > > > > > > > > TTL).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Do we need to keep the existing Client to
> > > > > > > > > > > > > > > Server A session warm (or perhaps to probe
> > > > > > > > > > > > > > > periodically) to see if Server A is capable
> > > > > > > > > > > > > > > of handling the Client again by a server
> > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers
> > > > > > > > > > > > > > > to the IP
> > > > > > > address)?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Server B accepts things for a while and then
> > > > > > > > > > > > > > > is instructed/decides to redirect traffic back to A.
> > > > > > > > > > > > > > > Server A is left still overload configured
> > > > > > > > > > > > > > > to redirect to B.  How should the client
> > > > > > > > > > > > > > > handle this as there is no suitable
> > > > > > > > > > > > > > Server?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [Med] This is a service configuration problem.
> > > > > > > > > > > > > > We may
> > > > ask:
> > > > > > > > > > > > > > > maintenance.  Server B accepts things for a
> > > > > > > > > > > > > > > while and then is instructed (in probable
> > > > > > > > > > > > > > > user
> > > > > > > > > > > > > > > error) to redirect traffic back to A
> > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A
> > > > > > > > > > > > > > being alive and able to
> > > > > > > > > > > > > respond
> > > > > > > > > > > > > > [Jon] With my better understanding of TTL we
> > > > > > > > > > > > > > still have an issue if the TTL expires and
> > > > > > > > > > > > > > Server A is having an extended
> > > > > > > outage.
> > > > > > > > > > > > > > > ____________________________________________
> > > > > > > > > > > > > > > ___ Dots mailing list [email-masked]
> > > > > > > > > > > > > > ______________________________________________
> > > > > > > > > > > > > > _ Dots mailing list [email-masked]
> > > > > > > > > > > > > > ______________________________________________
> > > > > > > > > > > > > > _ Dots mailing list [email-masked]

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 9 Apr 2018 09:39:18 +0100

Hi all,

Should 'ttl' actually be 'lifetime' to remove any confusion over whether
this is DNS TTL usage or not   ?

Otherwise see inline [Jon]

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 09 April 2018 09:23
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling

Above text looks good.

[Jon]  Later in the text, there is reference to a minimum of 5 minutes
before being able to switch back to the original DOTS server.  Don't we need
to say a 5 minute (300 secs) minimum here?

>       in Section 4.1, for creating new requests.

It looks too restrictive, typically the DNS TTL values are short-lived
(e.g.. few seconds) but the sessions are long-lived. 
Why not replace "for creating new requests" with "for creating new DOTS
session" ?

[Jon] I think that once the alternate DOTS server's lifetime has expired,
the DOTS client should try to establish a connection with the appropriate
"normal" DOTS servers, if that fails, continue to use the alternate DOTS
server, but periodically retry the "normal" servers to try to maintain
resilience of service.  After all, the outage (e.g. maintenance window) of
the original DOTS server may have to be extended, and being down, cannot
respond with a 3.00 to instruct DOTS client to stay with the alternate DOTS
server.

--Tiru

> > existing sessions after the TTL expires, but after the TTL expires 
> > it must consider the IP address stale and not establish new (D)TLS 
> > sessions.
> >
> > Cheers,
> > -Tiru
> >
> > > The below proposed change does not look good to me, its causing 
> > > the DOTS client to ping-pong between multiple DOTS servers because 
> > > of the TTL
> value.
> > > clients to an alternate server and avoid bouncing the existing 
> > > DOTS clients
> > which
> > > > > > > > > The proposed update restricts the client no to do a 
> > > > > > > > > DNS lookup using the alternate FQDN, further 
> > > > > > > > > associating a TTL with the name complicates the 
> > > > > > > > > functionality on the DOTS client to re-establish 
> > > > > > > > > My suggestion is to let the DOTS client continue to 
> > > > > > > > > use the alternate DOTS
> > > > > > > server
> > > > > > > > Triggers for redirect and for falling back to the 
> > > > > > > > nominal configuration are deployment-specific. The 
> > > > > > > > current spec allows for almost all the cases
> > > > > > > discussed
> > > > > > > > so far:
> > > > > > > >
> > > > > > > > (1) Redirect for the request in progress: A server does 
> > > > > > > > so by returning
> > > > > > > TTL=0.
> > > > > > > > can reply with a redirect code any time before the 
> > > > > > > > expiry of the TTL. A
> > > > > > > long TTL
> > > > > > > only reason for adding alt-server-record in the response 
> > > > > > > is DNS server may not be reachable by the DOTS server 
> > > > > > > because of a DDoS
> > > > attack.
> > > > > > >
> > > > > >
> > > > > > [Med] Yes. Note that even if the name resolution was 
> > > > > > allowed, the client has to deal with the TTL indicated in 
> > > > > > the response...which is exactly the same as (1) and (2).
> > > > > >
> > > > > >
> > > > > > alt-server should be handling the traffic before handling 
> > > > > > back to the original primary server.  It either has to be 
> > > > > > one or the other, or they have to
> > > > have different names.
> > > > > > > > > ahead-of-time the TTL value after which the DOTS 
> > > > > > > > > client should disconnect communicating with the 
> > > > > > > > > alternate DOTS server and re-establish (D)TLS session 
> > > > > > > > > with the primary DOTS
> > > server.
> > > > > > > >
> > > > > > > > [Med] It depends on the nature of the redirect: 
> > > > > > > > overload, planned
> > > > > > > maintenance,
> > > > > > > DOTS client to an optimal alternate server, where the 
> > > > > > > client can continue to send migration requests without a 
> > > > > > > frequent ping-pong
> > > > between servers.
> > > > > >
> > > > > > > > > > From: Dots [mailto:[email-masked]] On Behalf 
> > > > > > > > > > > >    to a PUT request from the DOTS client or 
> > > > > > > > > > > > convey the error
> > > > > > > response
> > > > > > > > > > > > > different DOTS server only if the alternate 
> > > > > > > > > > > > > DOTS server has the capacity to handle the 
> > > > > > > > > > > > > requests from the
> > > > > > > > > > > > DOTS client.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If the DOTS client has been redirected to a 
> > > > > > > > > > > > > DOTS server to which it has already sent the 
> > > > > > > > > > > > > mitigation request within the last five 
> > > > > > > > > > > > > minutes, it MUST ignore the redirection and 
> > > > > > > > > > > > > try reaching others servers listed in the 
> > > > > > > > > > > > > local configuration or discovered using 
> > > > > > > > > > > > > dynamic means
> > > > > > > > > > > > > > From: Dots [mailto: [email-masked]] 
> > > > > > > > > > > > > > On Behalf Of [email-masked]
> > > > > > > > > > > > > > > [mailto:[email-masked]] De la part 
> > > > > > > > > > > > > > > de Jon Shallow Envoyé : mercredi 4 avril 2018
15:31 À :
> > > > > > > > > > > > > > > I have implemented the 300 
> > > > > > > > > > > > > > > Redirected-Signal in my DOTS
> > > > > > code.
> > > > > > > > > > > > > > > How is the traffic redirected back to 
> > > > > > > > > > > > > > > Server A once maintenance / overloading etc.
has finished?
> > > > > > > > > > > > > > back to the "base" DOTS servers 
> > > > > > > > > > > > > > configuration that was provisioned to the
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal.
The ttl
> > > > > > > definition is
> > > > > > > > > > > > > > > periodically) to see if Server A is 
> > > > > > > > > > > > > > > capable of handling the Client again by a 
> > > > > > > > > > > > > > > server response extension to the protocol 
> > > > > > > > > > > > > > > (e.g. a
> > > > > > > > > > > > > > > 3.01)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only 
> > > > > > > > > > > > > > > refers to the IP
> > > > > > > address)?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Server A says "Redirect to Server B" due 
> > > > > > > > > > > > > > > to
> > > > overloading.
> > > > > > > > > > > > > > > Server B accepts things for a while and 
> > > > > > > > > > > > > > > then is instructed/decides to redirect traffic
back to A.
> > > > > > > > > > > > > > > I agree that there needs to be 
> > > > > > > > > > > > > > > co-ordination between Server A and Server 
> > > > > > > > > > > > > > > B, but user error may
> > > > creep in.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Usability #3
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > probable user
> > > > > > > > > > > > > > versus Server A down and not responding due 
> > > > > > > > > > > > > > to
> > > > > maintenance.
> > > > > > > > > > > > > > > __________________________________________
> > > > > > > > > > > > > > > __ ___ Dots mailing list [email-masked] 
> > > > > > > > > > > > > > __ _ Dots mailing list [email-masked] 
> > > > > > > > > > > > > > __ _ Dots mailing list [email-masked]

---

From: <[email-masked]>
Date: Mon, 9 Apr 2018 08:56:39 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 9 avril 2018 10:39
> À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]

[Med] we do already have a lifetime in the cbor mapping table. So, I suggest to maintain ttl but focus on its definition to avoid confusion. 

> to say a 5 minute (300 secs) minimum here?

[Med] That reference is when explicit redirect signals are involved. 

> "normal" DOTS servers,

[Med] Bingo.

 if that fails, continue to use the alternate DOTS
> resilience of service. 

[Med] The document does not specify the behavior for selecting among multiple servers. So, this details are out of scope. 

 After all, the outage (e.g. maintenance window) of
> respond with a 3.00 to instruct DOTS client to stay with the alternate DOTS

[Med] For such cases, it is safe to return an indefinite TTL + alternate server to coordinate the fallback behavior. 

> > > > > > > > > > > > > DOTS server to
> > > > > > > > > > > > > try to contact other DOTS
> > > > > > > > > > > > >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Apr 2018 10:08:18 +0000

> Sent: Monday, April 9, 2018 2:27 PM
> To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy
> > À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN;
> [Med] we do already have a lifetime in the cbor mapping table. So, I suggest to
> maintain ttl but focus on its definition to avoid confusion.

Agreed.

> > before being able to switch back to the original DOTS server.  Don't
> > we need to say a 5 minute (300 secs) minimum here?
> 

Yup.

> > [Jon] I think that once the alternate DOTS server's lifetime has
> > expired, the DOTS client should try to establish a connection with the
> > appropriate "normal" DOTS servers,
> 
> [Med] Bingo.

No,  DNS TTL lifetime does not mean existing session has to be disconnected 
after the TTL expires. 

-Tiru

> [Med] The document does not specify the behavior for selecting among multiple
> servers. So, this details are out of scope.
> 
> > the original DOTS server may have to be extended, and being down,
> > cannot respond with a 3.00 to instruct DOTS client to stay with the
> > alternate DOTS server.
> >
> 
> > > > I partially agree with the suggested update.  A IP address is
> > > > cached until the TTL value expires, the DOTS client need not
> > > > disconnect existing sessions after the TTL expires, but after the
> > > > TTL expires it must consider the IP address stale and not
> > > > > value of 300 seconds.  The text could read (including referring
> > > > > to the
> > > > optional
> > > > >    ttl:  Time to live (TTL) of the alternate DOTS server,
> > > > > represented
> > as
> > > > >       an integer number of seconds.  That is, the time interval
> > > > > that
> > the
> > > > >       If the alternate DOTS server TTL has expired, the DOTS
> > > > > client
> > MUST
> > > > > the DOTS client to ping-pong between multiple DOTS servers
> > > > > because of the TTL
> > > value.
> > > > > The alternate server should serve the DOTS client till there is
> > > > > a planned maintenance, if it is getting over-subscribed it
> > > > > should re-direct the new
> > > > DOTS
> > > > > >       '0' means that an alternate IP address is only to be
> > > > > > used for
> > the
> > > > > >       request in progress, and consequently that IP address
> > > > > > should
> > not
> > > > > >       be cached.
> > > > > >
> > > > > >       If 'alt-server-record' has expired, the DOTS client MUST
> > > > > > use
> > the
> > > > > >       the alternate DOTS server may be cached for use by a
> > > > > > DOTS
> > client.
> > > > > >
> > > > > >       '0' means that the alternate DOTS server is only to be
> > > > > > used
> > for the
> > > > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/bl
> > > > > > ob
> > > > > > /m
> > > > > > aste
> > > > > > r/draf
> > > > > > > > -----Message d'origine----- De : Jon Shallow
> > > > > > > > [mailto:[email-masked]]
> > > > > > > > > > > (D)TLS session with the primary DOTS server after
> > > > > > > > > > > the
> > > > > > > TTL expires.
> > > > > > > > > > (1) Redirect for the request in progress: A server
> > > > > > > > > > does so by returning
> > > > > > > > > TTL=0.
> > > > > > > > > > (2) The alternate server is not involved in fall back
> > > > > > > > > > to the nominal
> > > > > > > > > server: upon
> > > > > > > > > > (3) Redirect to an alternate server, which in turn
> > > > > > > > > > will instruct the client
> > > > > > > > > to
> > > > > > > > > > redirect to the "base" configuration:  a TTL is
> > > > > > > > > > provided and the alternate
> > > > > > > > > server
> > > > > > > > > > > alternate DOTS server and re-establish (D)TLS
> > > > > > > > > > > session with the primary DOTS
> > > > > server.
> > > > > > > > > >
> > > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is
> > > > > > > > a good safety net.
> > > > > > > > ~jon3
> > > > > > > >
> > > > > > > > > I have seen TURN servers being deployed for several
> > > > > > > > > years with
> > > > > > > > re-direction
> > > > > > > > > > > > From: Dots [mailto:[email-masked]] On
> > > > > > > > > > > > behavior. I don't want to over-specify the
> > > > > > > > > > > > redirect
> > behavior.
> > > > > > > > > > > >
> > > > > > > > > > > > > Envoyé : jeudi 5 avril 2018 12:06 À : Jon
> > > > > > > > RE:
> > > > > > > > > > > > > > - Surely, any response, unsolicited or
> > > > > > > > > > > > > > otherwise can contain a
> > > > > > > > > > > > > > 3.00
> > > > > > > > > > > > > >       A DOTS client MUST NOT use an alternate
> > > > > > > > > > > > > > IP address to
> > > > > > > > contact
> > > > > > > > > its
> > > > > > > > > > > > > >       A DOTS client MUST NOT use an alternate
> > > > > > > > > > > > > > IP address to
> > > > > > > > contact
> > > > > > > > > its
> > > > > > > > > > > > > I don't think the above restriction is correct
> > > > > > > > > > > > > for the following
> > > > > > > > > reasons:
> > > > > > > > > > > > >
> > > > > > > > > > > > > 2) If the DNS server is reachable, the client
> > > > > > > > > > > > > may want to a DANE lookup to get the IP
> > > > > > > > > > > > > addresses and certificate to validate the
> > > > > > > > > > > > > > I updated the draft with the text additions
> > > > > > > > > > > > > > that were discussed in this thread. The
> > > > > > > > > > > > > > changes can be
> > found at:
> > > > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-s
> > > > > > > > > > > > > > ig
> > > > > > > > > > > > > > na
> > > > > > > > > > > > > > l-
> > > > > > > > > > > > > channel/blob/master/draf
> > > > > > > > > > > > > > > The TTL value returned under
> > > > > > > > > > > > > > > alt-server-record is equivalent to the DNS
> > > > > > > > > > > > > > > TTL value. A DDoS mitigation provider with
> > > > > > > > > > > > > > > multiple DOTS servers typically re-directs a
> > > > > > > > > > > > > > > DOTS client to a different DOTS server only
> > > > > > > > > > > > > > > if the alternate DOTS server has the
> > > > > > > > > > > > > > > capacity to handle the requests from the
> > > > > > > > > > > > > > DOTS client.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > [mailto:[email-masked]] De la
> > > > > > > > > > > > > > > > > part de Jon Shallow Envoyé : mercredi 4
> > > > > > > > > > > > > > > > > avril 2018
> > 15:31 À :
> > > > > > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > Objet :
> > > > > > > > > > > > > > > > >    4.  Having redirected the DOTS
> > > > > > > > > > > > > > > > > client, DOTS server A ceases
> > > > > > > > > > > > > sending
> > > > > > > > > > > > > > > > Another approach would be to not require
> > > > > > > > > > > > > > > > any redirect signal from server
> > > > > > > > > > > > > > B.
> > > > > > > > > > > > > > > > > Do we need to keep the existing Client
> > > > > > > > > > > > > > > > > to Server A session warm (or perhaps to
> > > > > > > > > > > > > > > > > probe
> > > > > > > > > > > > > > > > > capable of handling the Client again by
> > > > > > > > > > > > > > > > > a server response extension to the
> > > > > > > > > > > > > > > > > protocol (e.g. a
> > > > > > > > > > > > > > > > > 3.01)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > think it makes sense to probe or maintain
> > > > > > > > > > > > > > > > a session with
> > > > > > > > server
> > > > > > > > > A.
> > > > > > > > > > > > > > > > > Server A is left still overload
> > > > > > > > > > > > > > > > > configured to redirect to B.  How should
> > > > > > > > > > > > > > > > * the client to log the error and notify
> > > > > > > > > > > > > > > > the
> > > > > > > administrator.
> > > > > > > > > > > > > > > > > co-ordination between Server A and
> > > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server
> > > > > > > > > > > > > > > > A being alive and able to
> > > > > > > > > > > > > > > respond
> > > > > > > > > > > > > > > > versus Server A down and not responding
> > > > > > > > > > > > > > > > due to
> > > > > > > maintenance.
> > > > > > > > > > > > > > > > [Jon] With my better understanding of TTL
> > > > > > > > > > > > > > > > we still have an issue if the TTL expires
> > > > > > > > > > > > > > > > and Server A is having an extended
> > > > > > > > > outage.
> > > > > > > > > > > > > > > > > ________________________________________
> > > > > > > > > > > > > > > > > __ __ ___ Dots mailing list
> > > > > > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > > > > > __ __ _ Dots mailing list [email-masked]
> > > > > > > > > > > > > > > > __ __ _ Dots mailing list [email-masked]

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 9 Apr 2018 11:22:15 +0100

Hi Tiru/Med,

See inline [Jon2]

Regards

Jon

> [Med] we do already have a lifetime in the cbor mapping table. So, I 
> suggest to maintain ttl but focus on its definition to avoid confusion.

Agreed.

> > [Jon]  Later in the text, there is reference to a minimum of 5 
> > minutes before being able to switch back to the original DOTS 
> > server.  Don't we need to say a 5 minute (300 secs) minimum here?
> 

Yup.

> > It looks too restrictive, typically the DNS TTL values are 
> > short-lived (e.g.. few seconds) but the sessions are long-lived.
> > expired, the DOTS client should try to establish a connection with 
> > the appropriate "normal" DOTS servers,
> 
> [Med] Bingo.

[Jon2] I guess that I am missing something here.  A DOTS client, when using
a resolver library, has no knowledge of when an IP's DNS TTL will expire or
has expired - a lookup request to the library may or may not refresh the
remaining TTL.

[Jon2] However, I thought that TTL referred to the alternate DOTS server
lifetime and now had nothing to do with DNS TTL.

[Jon2] My text immediately below implies that the current session should
only get disconnected if the DOTS client is able to start using another
(likely to be the original) DOTS server.

-Tiru

> > server, but periodically retry the "normal" servers to try to 
> > maintain resilience of service.
> 
> [Med] The document does not specify the behavior for selecting among 
> multiple servers. So, this details are out of scope.

[Jon2] Agreed the details are out of scope, but would follow the lines of "
the DOTS client MUST
      use the DOTS server(s), that was provisioned using means discussed
      in Section 4.1, for creating new requests."
~jon2
> [Med] For such cases, it is safe to return an indefinite TTL + 
> alternate server to coordinate the fallback behavior.
> 
> > --Tiru
> >
> > >
> > > > Envoyé : lundi 9 avril 2018 08:51 À : Jon Shallow; BOUCADAIR 
> > > > disconnect existing sessions after the TTL expires, but after 
> > > > the TTL expires it must consider the IP address stale and not 
> > > > > value of 300 seconds.  The text could read (including 
> > > > > referring to the
> > > > optional
> > > > >       an integer number of seconds.  That is, the time 
> > > > > interval that
> > the
> > > > > The below proposed change does not look good to me, its 
> > > > > causing the DOTS client to ping-pong between multiple DOTS 
> > > > > servers because of the TTL
> > > value.
> > > > > The alternate server should serve the DOTS client till there 
> > > > > is a planned maintenance, if it is getting over-subscribed it 
> > > > > should re-direct the new
> > > > DOTS
> > > > > >       If no 'ttl' is returned in a redirect response, this 
> > > > > > is
> > equivalent
> > > > > >       If 'alt-server-record' has expired, the DOTS client 
> > > > > > MUST use
> > the
> > > > > > represented as
> > > > > >       request in progress, and consequently the alternate 
> > > > > > DOTS server entry should not
> > > > > >       be cached.
> > > > > >
> > > > > >       If no 'ttl' is returned in a redirect response, this 
> > > > > > is
> > equivalent
> > > > > > client MUST
> > > > > > > > Envoyé : vendredi 6 avril 2018 14:57 À : BOUCADAIR 
> > > > > > > > Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
Objet : RE:
> > > > > > > > > > > The proposed update restricts the client no to do 
> > > > > > > > > > > a DNS lookup using the alternate FQDN, further 
> > > > > > > > > > > My suggestion is to let the DOTS client continue 
> > > > > > > > > > > to use the alternate DOTS
> > > > > > > > > server
> > > > > > > > > > (2) The alternate server is not involved in fall 
> > > > > > > > > > back to the nominal
> > > > > > > > > server: upon
> > > > > > > > > > expiry of ttl of all alternate IP addresses, then 
> > > > > > > > > > fall back automatically
> > > > > > > > > to the
> > > > > > > > > > nominal server.
> > > > > > > > > Yes, but (1) and (2) complicate the functionality of 
> > > > > > > > > the DOTS
> > > > > client.
> > > > > > > >
> > > > > > > > > only reason for adding alt-server-record in the 
> > > > > > > > > response is DNS server may not be reachable by the 
> > > > > > > > > DOTS server because of a DDoS
> > > > > > attack.
> > > > > > > > >
> > > > > > > >
> > > > > > > > allowed, the client has to deal with the TTL indicated 
> > > > > > > > in the response...which is exactly the same as (1) and (2).
> > > > > > > >
> > > > > > > >
> > > > > > > > alt-server should be handling the traffic before 
> > > > > > > > handling back to the original primary server.  It either 
> > > > > > > > has to be one or the other, or they have to
> > > > > > have different names.
> > > > > > > > Handling the TTL for DNS refresh is normally handled by 
> > > > > > > > a resolver library, updated by the DNS packets coming in 
> > > > > > > > - unusual for an application
> > > > > > > to have to do that.
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >  I
> > > > > > > > > It's the primary DOTS server responsibility to point 
> > > > > > > > > the DOTS client to an optimal alternate server, where 
> > > > > > > > > the client can continue to send migration requests 
> > > > > > > > > without a frequent ping-pong
> > > > > > between servers.
> > > > > > > >
> > > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time 
> > > > > > > > is a good safety net.
> > > > > > > > ~jon3
> > > > > > > >
> > > > > > > > > > > > I don't see the NEW text as a restriction but as 
> > > > > > > > > > > > a simplification of the
> > > > > > > > > > > client's
> > > > > > > > > > > > > >    code 3.00 in a unidirectional 
> > > > > > > > > > > > > > notification response from the
> > > > > > > > > DOTS
> > > > > > > > > > > > > >    server.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >       A DOTS client MUST NOT use an 
> > > > > > > > > > > > > > alternate IP address to
> > > > > > > > contact
> > > > > > > > > its
> > > > > > > > > > > > > >       A DOTS client MUST NOT use an 
> > > > > > > > > > > > > > alternate IP address to
> > > > > > > > contact
> > > > > > > > > its
> > > > > > > > > > > > > expires, DNS lookup can be performed by the 
> > > > > > > > > > > > > DOTS client using the alternate DOTS
> > > > > > > > server
> > > > > > > > > FQDN.
> > > > > > > > > > > > > > > [mailto:[email-masked]
> > > > > > > > > > > > > > > ] Envoyé : mercredi 4 avril 2018 17:40 À : 
> > > > > > > > > > > > > > > Jon Shallow; BOUCADAIR Mohamed IMT/OLN; 
> > > > > > > > > > > > > > > [email-masked]
> > > > > Objet : RE:
> > > > > > > > > > > > > > > multiple DOTS servers typically re-directs 
> > > > > > > > > > > > > > > a DOTS client to a different DOTS server 
> > > > > > > > > > > > > > > only if the alternate DOTS server has the 
> > > > > > > > > > > > > > > If the DOTS client has been redirected to 
> > > > > > > > > > > > > > > a DOTS server to which it has already sent 
> > > > > > > > > > > > > > > the mitigation request within the last 
> > > > > > > > > > > > > > > five minutes, it MUST ignore the 
> > > > > > > > > > > > > > > redirection and try reaching others 
> > > > > > > > > > > > > > > servers listed in the local configuration 
> > > > > > > > > > > > > > > This prevents infinite ping-ponging 
> > > > > > > > > > > > > > > between servers in case of redirection loops.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -Tiru
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Of Jon Shallow
> > > > > > > > > > > > > > > > > part de Jon Shallow Envoyé : mercredi 
> > > > > > > > > > > > > > > > > 4 avril 2018
> > 15:31 À :
> > > > > > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > Objet :
> > > > > > > > > > > > > > > > >        server signals.  The DOTS 
> > > > > > > > > > > > > > > > > client likewise stops sending
> > > > > > > > > > > client
> > > > > > > > > > > > > > > > > to Server A session warm (or perhaps 
> > > > > > > > > > > > > > > > > to probe
> > > > > > > > > > > > > > > > > capable of handling the Client again 
> > > > > > > > > > > > > > > > > by a server response extension to the 
> > > > > > > > > > > > > > > > > protocol (e.g. a
> > > > > > > > > > > > > > > > > 3.01)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > think it makes sense to probe or 
> > > > > > > > > > > > > > > > maintain a session with
> > > > > > > > server
> > > > > > > > > A.
> > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" 
> > > > > > > > > > > > > > > > > due to
> > > > > > overloading.
> > > > > > > > > > > > > > > > > Server B accepts things for a while 
> > > > > > > > > > > > > > > > > and then is instructed/decides to 
> > > > > > > > > > > > > > > > > redirect traffic
> > back to A.
> > > > > > > > > > > > > > > > > configured to redirect to B.  How 
> > > > > > > > > > > > > > > > > should the client handle this as there 
> > > > > > > > > > > > > > > > > is no suitable
> > > > > > > > > > > > > > > > Server?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > (perhaps because it has hit an 
> > > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in 
> > > > > > > > > > > > > > > > Server A being alive and able to
> > > > > > > > > > > > > > > respond
> > > > > > > > > > > > > > > > expires and Server A is having an 
> > > > > > > > > > > > > > > > extended
> > > > > > > > > outage.
> > > > > > > > > > > > > > > > > ______________________________________
> > > > > > > > > > > > > > > > > __ __ __ ___ Dots mailing list 
> > > > > > > > > > > > > > > > > [email-masked] 
> > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/
> > > > > > > > > > > > > > > > > do
> > > > > > > > > > > > > > > > > ts
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > __ __ __ _ Dots mailing list 
> > > > > > > > > > > > > > > > [email-masked] 
> > > > > > > > > > > > > > > > __ __ __ _ Dots mailing list 
> > > > > > > > > > > > > > > > [email-masked]

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Apr 2018 10:47:54 +0000

> Sent: Monday, April 9, 2018 3:52 PM
> > > >       value means that the alternate DOTS server is to be used
> > > > until
> the
> [Jon2] I guess that I am missing something here.  A DOTS client, when using a
> resolver library, has no knowledge of when an IP's DNS TTL will expire or has
> expired - a lookup request to the library may or may not refresh the remaining
> TTL.

Yes, the resolver library is only called for new DOTS session. 

> lifetime and now had nothing to do with DNS TTL.

No, It is DNS TTL to handle the scenario when DNS server is not available.

> 
> [Jon2] My text immediately below implies that the current session should only
> get disconnected if the DOTS client is able to start using another (likely to be the
> original) DOTS server.

I don't see the need to disconnect existing session just because DNS TTL expires. 

-Tiru

> > > > > > >    ttl:  Time to live (TTL) of alternate records,
> > > > > > > represented as
> an
> > > > > > >       DOTS server(s) that was provisioned using means
> > > > > > > discussed
> in
> > > > > > >       Section 4.1.  Furthermore, a DOTS client MUST NOT use
> > > > > > > the
> alt-
> > > > > > >       DOTS server(s) that was provisioned using means
> > > > > > > discussed
> in
> > > > > > >       Section 4.1.
> > > > > > >
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > Jon
> > > > > > >
> > > > > > > > > > > > > > > a DOTS server to
> > > > > > > > > > > > > > >       DOTS server upon expiry of the
> > > > > > > > > > > > > > > associated
> TTL.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >       DOTS server upon expiry of the
> > > > > > > > > > > > > > > associated
> TTL.
> > > > > > > > > > > > > > > Furthermore, a
> > > > > > > > > > > > DOTS
> > > > > > > > > > > > > > > > We can add the following lines to avoid
> > > > > > > > > > > > > > > > loops
> :
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Server A once maintenance /
> > > > > > > > > > > > > > > > > > overloading
> etc.
> > > has finished?
> > > > > > > > > > > > > > > > > > as it going to be shut down because of

---

From: <[email-masked]>
Date: Mon, 9 Apr 2018 11:19:09 +0000

Re-,

Focusing on this part of your answer:

"No,  DNS TTL lifetime does not mean existing session has to be disconnected 
after the TTL expires."

This is exactly the disconnect. We are not discussing **DNS TTL** but the validity time of a an alternate server as provided in a DOTS redirect signal. 

If a finite validity time is provided, the client will use that alternate server till that validly time expires. Passed that timer, the client will contact its "normal" servers to place requests. That behavior is straightforward. 

If you insist to interpret TTL as DNS TTL, then RFC1035 says the following: 

" TTL             a 32 bit signed integer that specifies the time interval
                that the resource record may be cached before the source
                of the information should again be consulted. "
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In our case, the source of the information is the normal server :)

Cheers,
Med

> Envoyé : lundi 9 avril 2018 12:08
> suggest to
> multiple
> > [Med] For such cases, it is safe to return an indefinite TTL + alternate
> server to
> > coordinate the fallback behavior.
> >
> > > --Tiru
> > >
> > > >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Apr 2018 11:29:20 +0000

> Sent: Monday, April 9, 2018 4:49 PM
> This is exactly the disconnect. We are not discussing **DNS TTL** but the
> validity time of a an alternate server as provided in a DOTS redirect signal.

When the server can explicitly re-direct the client, why provide the validity time of an alternate server ?

> 
> If a finite validity time is provided, the client will use that alternate server till that
> validly time expires. Passed that timer, the client will contact its "normal" servers
> to place requests. That behavior is straightforward.
> 

Yes, caching is done based on TTL to avoid DNS lookups but it does not mean the client has to disconnect existing 
sessions after the TTL expires.

-Tiru

> > Tirumaleswar Reddy Envoyé : lundi 9 avril 2018 12:08 À : BOUCADAIR
> > > To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar
> > No,  DNS TTL lifetime does not mean existing session has to be
> > disconnected after the TTL expires.
> >
> > -Tiru
> >
> > >
> > > > cannot respond with a 3.00 to instruct DOTS client to stay with
> > > > the alternate DOTS server.
> > > >
> > >
> > > > > > >       use the DOTS server(s) that was provisioned using
> > > > > > > means
> > > > discussed
> > > > > > >       in Section 4.1.
> > > > > > >
> > > > > > > Konda, Tirumaleswar Reddy
> > > > > > > is a planned maintenance, if it is getting over-subscribed
> > > > > > > it should re-direct the new
> > > > > > DOTS
> > > > > > > clients to an alternate server and avoid bouncing the
> > > > > > > existing DOTS clients
> > > > > > which
> > > > > > > >       request in progress, and consequently that IP
> > > > > > > > address should
> > > > not
> > > > > > > >       be cached.
> > > > > > > >
> > > > > > > >       Section 4.1.  Furthermore, a DOTS client MUST NOT
> > > > > > > > use the
> > alt-
> > > > > > > >       '0' means that the alternate DOTS server is only to
> > > > > > > > be used
> > > > for the
> > > > > > > > > Envoyé : vendredi 6 avril 2018 15:33 À : BOUCADAIR
> > > > > > > > > Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
> Objet : RE:
> > > > > > > > > > > > > Envoyé : vendredi 6 avril 2018 07:07 À :
> > > > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow;
> [email-masked] Objet : RE:
> > > > > > > > > > > > > The proposed update restricts the client no to
> > > > > > > > > > > > > do a DNS lookup using the alternate FQDN,
> > > > > > > > > > > > > further associating a TTL with the name
> > > > > > > > > > > > > complicates the functionality on the DOTS client
> > > > > > > > > > > > > to re-establish (D)TLS session with the primary
> > > > > > > > > > > > > DOTS server after the
> > > > > > > > > TTL expires.
> > > > > > > > > > alt-server-record and then the TTL after which that
> > > > > > > > > > the alt-server should be handling the traffic before
> > > > > > > > > > handling back to the original primary server.  It
> > > > > > > > > > Handling the TTL for DNS refresh is normally handled
> > > > > > > > > > by a resolver library, updated by the DNS packets
> > > > > > > > > > coming in - unusual for an application
> > > > > > > > > to have to do that.
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >  I
> > > > > > > > > > > > > don't think the DOTS mitigation provider will
> > > > > > > > > > > > > know ahead-of-time the TTL value after which the
> > > > > > > > > > > > > DOTS client should disconnect communicating with
> > > > > > > > > > > > > the alternate DOTS server and re-establish
> > > > > > > > > > > the DOTS client to an optimal alternate server,
> > > > > > > > > > > where the client can continue to send migration
> > > > > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong
> > > > > > > > > > time is a good safety net.
> > > > > > > > > > ~jon3
> > > > > > > > > >
> > > > > > > > > > > > > > I don't see the NEW text as a restriction but
> > > > > > > > > > > > > > as a simplification of the
> > > > > > > > > > > > > client's
> > > > > > > > > > > > > > > >    to a PUT request from the DOTS client
> > > > > > > > > > > > > > > > or convey the error
> > > > > > > > > > > response
> > > > > > > > > > > > > > > > maintenance outage other than by closing
> > > > > > > > > > > > > > > > the
> > > > session.
> > > > > > > > > > > > > > > I don't think the above restriction is
> > > > > > > > > > > > > > > correct for the following
> > > > > > > > > > > reasons:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2) If the DNS server is reachable, the
> > > > > > > > > > > > > > > client may want to a DANE lookup to get the
> > > > > > > > > > > > > > > IP addresses and certificate to validate the
> > > > > > > > > > > > > > > > > [mailto:[email-masked]
> > > > > > > > > > > > > > > > > om] Envoyé : mercredi 4 avril 2018 17:40
> > > > > > > > > > > > > > > > > alt-server-record is equivalent to the
> > > > > > > > > > > > > > > > > different DOTS server only if the
> > > > > > > > > > > > > > > > > alternate DOTS server has the capacity
> > > > > > > > > > > > > > > > > If the DOTS client has been redirected
> > > > > > > > > > > > > > > > > to a DOTS server to which it has already
> > > > > > > > > > > > > > > > > sent the mitigation request within the
> > > > > > > > > > > > > > > > > last five minutes, it MUST ignore the
> > > > > > > > > > > > > > > > > > Behalf Of Jon Shallow
> > > > > > > > > > > > > > > > > > Cheers, Med
> > > > > > > > > > > > > > > > > > > -----Message d'origine----- De :
> > > > > > > > > > > > > > > > > > > Dots [mailto:[email-masked]]
> > > > > > > > > > > > > > > > > > > De la part de Jon Shallow Envoyé :
> > > > > > > > > > > > > > > > > > > mercredi 4 avril 2018
> > > > 15:31 À :
> > > > > > > > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > > Objet :
> > > > > > > > > > > > > > > > > > > This then raises some questions
> > > > > > > > > > > > > > > > > > > about
> > > > usability.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Usability #1
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >        signals to DOTS server A.
> > > > > > > > > > > > > > > > > > > DOTS session 1 is
> > > > > > > > > > > terminated.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > My assumption is that Server B sends
> > > > > > > > > > > > > > > > > > > a redirect to go back to Server A as
> > > > > > > > > > > > > > > > > > language (I read it as being
> > > > > > > > > > > > > > > > > > > perhaps to probe
> > > > > > > > > > > > > > > > > > > by a server response extension to
> > > > > > > > > > > > > > > > > > > the protocol (e.g. a
> > > > > > > > > > > > > > > > > > > 3.01)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > [Med] Redirect was initially
> > > > > > > > > > > > > > > > > > introduced to manage a server
> > > > > > > > > > > > > > > > > > overload, so I
> > > > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise
> > > > > > > > > > > > > > > > > > the
> > > > question.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl
> > > > > > > > > > > > > > > > > > > only refers to the IP
> > > > > > > > > > > address)?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > should the client handle this as
> > > > > > > > > > > > > > > > > > > there is no suitable
> > > > > > > > > > > > > > > > > > Server?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > * the client to log the error and
> > > > > > > > > > > > > > > > > > notify the
> > > > > > > > > administrator.
> > > > > > > > > > > > > > > > > > > as it going to be shut down because
> > > > > > > > > > > > > > > > > > > of maintenance.  Server B accepts
> > > > > > > > > > > > > > > > > > > things for a while and then is
> > > > > > > > > > > > > > > > > > versus Server A down and not
> > > > > > > > > > > > > > > > > > responding due to
> > > > > > > > > maintenance.
> > > > > > > > > > > > > > > > > > > ____________________________________
> > > > > > > > > > > > > > > > > > > ____ __ __ ___ Dots mailing list
> > > > > > > > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinf
> > > > > > > > > > > > > > > > > > > o/do
> > > > > > > > > > > > > > > > > > > ts
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > ____ __ __ _ Dots mailing list
> > > > > > > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > > > > > > > dots
> > > > > > > > > > > > > > > > > > ____ __ __ _ Dots mailing list
> > > > > > > > > > > > > > > > > > [email-masked]
> > > > > > > > > > > > > > > > > > dots
> > > > > > > > > > > > > > > > ____ _ Dots mailing list [email-masked]

---

From: <[email-masked]>
Date: Mon, 9 Apr 2018 11:42:01 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 9 avril 2018 13:29

[Med] Involving the alternate server is one deployment mode among others. The current text allows for these two modes:
 
(1) redirect upon an explicit signal
(2) automatic fallback upon ttl expiry

Which one to pick is deployment-specific. 

TTL makes sense only for (2).

> sessions after the TTL expires.

[Med] It seems that I didn't made my point clear. I was explicitly referring to "...the source of the information should again be consulted".
Which means that, if we maintain the comparison with DNS, upon expiry of TTL the source of the information (our case=normal DOTS server) should be consulted.

I suggest we get out from the DNS thing, but focus on the functionality we want for TTL.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 9 Apr 2018 11:48:22 +0000

> Sent: Monday, April 9, 2018 5:12 PM
> > Tirumaleswar Reddy Envoyé : lundi 9 avril 2018 13:29 À : BOUCADAIR
> > > This is exactly the disconnect. We are not discussing **DNS TTL**
> > > but the validity time of a an alternate server as provided in a DOTS
> > > redirect
> > signal.
> >
> [Med] Involving the alternate server is one deployment mode among others.
> The current text allows for these two modes:
> 

I don't think (2) is required, HTTP does not support (2) for Temporary re-direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3).

> 
> >
> > >
> > > If a finite validity time is provided, the client will use that
> > > alternate
> > server till that
> > Yes, caching is done based on TTL to avoid DNS lookups but it does not
> > mean the client has to disconnect existing sessions after the TTL
> > expires.
> >
> 
> [Med] It seems that I didn't made my point clear. I was explicitly referring to
> "...the source of the information should again be consulted".
> Which means that, if we maintain the comparison with DNS, upon expiry of TTL
> the source of the information (our case=normal DOTS server) should be
> consulted.

No, client contacts the source of the information only when a new TCP/UDP session needs to be established.

Works for me.

-Tiru

---

From: <[email-masked]>
Date: Mon, 9 Apr 2018 12:19:48 +0000

Re-,

Glad to see that we both agree to get out from the DNS comparison. 

Please see inline.

Cheers,
Med

> Envoyé : lundi 9 avril 2018 13:48
> I don't think (2) is required, HTTP does not support (2) for Temporary re-
> direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3).
> 

[Med] The comparison with 307 is not accurate because that code assumes the following:

   The 307 (Temporary Redirect) status code indicates that the target
   resource resides temporarily under a different URI and the user agent
   MUST NOT change the request method if it performs an automatic
   redirection to that URI.  Since the redirection can change over time,   
   the client ought to continue using the original effective request URI
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   for future requests.
   ^^^^^^^^^^^^^^^^^^^

Supplying the TTL is the only way to master the automatic fall back while avoiding contacting the "normal" server during the "temporary redirect'.

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 9 Apr 2018 21:40:16 +0100

Hi,

See inline [Jon]

Regards

Jon

-----Original Message-----
From: [email-masked] [mailto: [email-masked]] 
Sent: 09 April 2018 13:20
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]
Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling

Re-,

[Jon] Also agree.  Perhaps 'ttl' should be renamed 'alt-server-ttl'.

Please see inline.

Cheers,
Med

> > > Mohamed IMT/OLN; Jon Shallow; [email-masked] Objet : Re: [Dots] 
> > > > This is exactly the disconnect. We are not discussing **DNS 
> > > > TTL** but the validity time of a an alternate server as provided 
> > > > in a DOTS redirect
> > > signal.
> > >
> > > When the server can explicitly re-direct the client, why provide 
> > > the validity time of an alternate server ?
> >
> I don't think (2) is required, HTTP does not support (2) for Temporary 
> re- direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3).
> 

[Jon] in the general potential overloading case of a specific DOTS server,
to redirect a DOTS client to an alternative DOTS server for a period of time
makes sense to me - and then the DOTS client can then come back again.  So,
to me, [2] is a valid option.

[Med] The comparison with 307 is not accurate because that code assumes the
following:

Supplying the TTL is the only way to master the automatic fall back while
avoiding contacting the "normal" server during the "temporary redirect'. 

[Jon] Agreed.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 05:30:33 +0000

> Sent: Tuesday, April 10, 2018 2:10 AM

If TTL expires, DOTS client cannot be re-directed when DDOS attack is active.
If a DOTS client does not honor the TTL value and continues to use the alternate server, the server should explicitly re-direct the client and if the client still continues to use the DOTS server, it should disconnect the (D)TLS session. 

-Tiru

---

From: <[email-masked]>
Date: Tue, 10 Apr 2018 06:31:02 +0000

Hi all, 

I think that we are converging. 

Below a text proposal which reflects the outcome of the discussion:

======

      A value of negative one (-1) indicates indefinite TTL.  This value
      means that the alternate DOTS server is to be used until the
      alternate DOTS server redirects the traffic with another 3.00
      response.

      If the alternate DOTS server TTL has expired, the DOTS client MUST
      use the DOTS server(s), that was provisioned using means discussed
      in Section 4.1.  This fall back mechanism is triggered immediately
      upon expiry of the TTL except when a DDoS attack is active.

      Requests issued by misbehaving DOTS clients which do not honor the
      TTL or react to explicit re-direct messages can be rejected by
      DOTS servers.

Cheers,
Med

> Envoyé : mardi 10 avril 2018 07:31
> If a DOTS client does not honor the TTL value and continues to use the
> alternate server, the server should explicitly re-direct the client and if
> the client still continues to use the DOTS server, it should disconnect the
> (D)TLS session.
> 
> -Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 06:46:10 +0000

> Sent: Tuesday, April 10, 2018 12:01 PM

Looks good. We may also want to say that 0 or too small value for ttl should be avoided.

-Tiru

> > > > > > Tirumaleswar Reddy Envoyé : lundi 9 avril 2018 13:29 À :
> > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked] Objet :
> > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling
> > > > > >
> > > > > > > "No,  DNS TTL lifetime does not mean existing session has to
> > > > > > > be
> > > > > > disconnected
> > > > > > > after the TTL expires."
> > > > > > >
> > > > > > > TTL** but the validity time of a an alternate server as
> > > > > > > provided in a DOTS redirect
> > > > > > signal.
> > > > > >
> > > > > > When the server can explicitly re-direct the client, why
> > > > > > provide the validity time of an alternate server ?
> > > > >
> > > > > [Med] Involving the alternate server is one deployment mode
> > > > > among
> > > others.
> > > [Jon] in the general potential overloading case of a specific DOTS
> > > server, to redirect a DOTS client to an alternative DOTS server for
> > > a period of
> > time
> > > makes sense to me - and then the DOTS client can then come back
> > > again.  So, to me, [2] is a valid option.
> > >
> > > Supplying the TTL is the only way to master the automatic fall back
> > > while avoiding contacting the "normal" server during the "temporary
> redirect'.
> > >
> > > [Jon] Agreed.
> >
> > alternate server, the server should explicitly re-direct the client
> > and if the client still continues to use the DOTS server, it should
> > disconnect the (D)TLS session.
> >
> > -Tiru

---

From: <[email-masked]>
Date: Tue, 10 Apr 2018 07:03:58 +0000

Re-,

The exact value to return is on the deployment side. If a server/provider decides that 0 or small value is to be returned (that is, redirect applies only for the ongoing request), why should the spec care about this?

Cheers,
Med

> Envoyé : mardi 10 avril 2018 08:46

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 09:16:16 +0000

> Sent: Tuesday, April 10, 2018 12:34 PM
> The exact value to return is on the deployment side. If a server/provider decides
> that 0 or small value is to be returned (that is, redirect applies only for the
> ongoing request), why should the spec care about this?

If 0 value is returned, and the client wants to send a requests to discover and configure the DOTS session configuration before sending the mitigation request, 0 value means the
client does not get to send the mitigation request. We may want to clarify that with 0 TTL value, re-direct applies only for the ongoing mitigation request and not for other type of requests. Further, too small value will adversely impact a DOTS client on slow links, e.g. TTL value expires by the time the mitigation request reaches the DOTS server after multiple retries.  

-Tiru

> > Tirumaleswar Reddy Envoyé : mardi 10 avril 2018 08:46 À : BOUCADAIR
> > > > Envoyé : mardi 10 avril 2018 07:31 À : Jon Shallow; BOUCADAIR
> > > > > > Envoyé : lundi 9 avril 2018 13:48 À : BOUCADAIR Mohamed
> > > > > > > > [mailto:[email-masked]] De la part de Konda,
> > > > > > > > > "No,  DNS TTL lifetime does not mean existing session
> > > > > > > > > has to be
> > > > > > > > disconnected
> > > > > > > > > after the TTL expires."
> > > > > > > > >
> > > > > [Jon] in the general potential overloading case of a specific
> > > > > DOTS server, to redirect a DOTS client to an alternative DOTS
> > > > > server for a period of
> > > > time
> > > > >    resource resides temporarily under a different URI and the
> > > > > user
> > agent
> > > > >    redirection to that URI.  Since the redirection can change
> > > > > over
> > time,
> > > > > Supplying the TTL is the only way to master the automatic fall
> > > > > back while avoiding contacting the "normal" server during the
> > > > > "temporary
> > > redirect'.
> > > > >
> > > > > [Jon] Agreed.
> > > >
> > > > If TTL expires, DOTS client cannot be re-directed when DDOS attack
> > > > is
> > active.
> > > > If a DOTS client does not honor the TTL value and continues to use
> > > > the alternate server, the server should explicitly re-direct the
> > > > client and if the client still continues to use the DOTS server,
> > > > it should disconnect the (D)TLS session.
> > > >
> > > > -Tiru
> >

---

From: <[email-masked]>
Date: Tue, 10 Apr 2018 09:21:42 +0000

Hi Jon,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 10 avril 2018 11:07
> We have this in place for ping-pong limitations
> 
>    has already communicated with within the last five (5) minutes, it
>    MUST ignore the redirection and try to contact other DOTS servers
>    listed in the local configuration or discovered using dynamic means
>    such as DHCP or SRV procedures.  It is RECOMMENDED that DOTS clients
>    support means to alert administrators about redirect loops.
> 

[Med] This one is to avoid oscillation when explicit redirects are in use. 

> Which I think still needs to be there.  So the use of something small for
> ttl is questionable.  A value of 0 could be used as a "one-shot"
> redirection, but how often will that in reality get used?

[Med] If TTL=0 is provided, this means that only the request in-progress will need to be redirected to the alternate server unless an attack is active. For example, if the redirected request is a mitigation request, the client will maintain the session with the alternate server till the attack is mitigated. Then, it will fall back to its normal server. This behavior applies whatever finite value returned in the TTL.

> Sent: 10 April 2018 08:04
> The exact value to return is on the deployment side. If a server/provider
> decides that 0 or small value is to be returned (that is, redirect applies
> only for the ongoing request), why should the spec care about this?
> 
> Cheers,
> Med
> 
> > > > > > re- direct (see
> https://tools.ietf.org/html/rfc7285#section-8.5.3).
> > > > > >
> > > > >

---

From: <[email-masked]>
Date: Tue, 10 Apr 2018 09:34:10 +0000

Re-,

Sounds reasonable. Below a text proposal: 

      A 'alt-server-ttl' parameter set to '0' may be returned for
      redirecting mitigation requests.  Such value means that the
      redirection applies only for the mitigation request in progress.
      Returning short 'alt-server-ttl' may adversely impact DOTS clients
      on slow links.  Returning short values should be avoided under
      such conditions.

Cheers,
Med

> Envoyé : mardi 10 avril 2018 11:16
> decides
> If 0 value is returned, and the client wants to send a requests to discover
> and configure the DOTS session configuration before sending the mitigation
> request, 0 value means the
> client does not get to send the mitigation request. We may want to clarify
> that with 0 TTL value, re-direct applies only for the ongoing mitigation
> request and not for other type of requests. Further, too small value will
> adversely impact a DOTS client on slow links, e.g. TTL value expires by the
> time the mitigation request reaches the DOTS server after multiple retries.
> 
> -Tiru
> 
> >
> > Cheers,
> > Med
> >
> > > > > > > re- direct (see https://tools.ietf.org/html/rfc7285#section-
> 8.5..3).
> > > > > > >
> > > > > >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 10 Apr 2018 09:50:32 +0000

> Sent: Tuesday, April 10, 2018 3:04 PM

Thanks, Med. Update looks good.

Cheers,
-Tiru

> > Tirumaleswar Reddy Envoyé : mardi 10 avril 2018 11:16 À : BOUCADAIR
> > > that 0 or small value is to be returned (that is, redirect applies
> > > only for
> > the
> > If 0 value is returned, and the client wants to send a requests to
> > discover and configure the DOTS session configuration before sending
> > the mitigation request, 0 value means the client does not get to send
> > the mitigation request. We may want to clarify that with 0 TTL value,
> > re-direct applies only for the ongoing mitigation request and not for
> > other type of requests. Further, too small value will adversely impact
> > a DOTS client on slow links, e.g. TTL value expires by the time the
> > mitigation request reaches the DOTS server after multiple retries.
> >
> > -Tiru
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > Tirumaleswar Reddy Envoyé : mardi 10 avril 2018 08:46 À :
> > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked] Objet : Re:
> > > > >       A value of negative one (-1) indicates indefinite TTL.
> > > > > This
> > value
> > > > >       Requests issued by misbehaving DOTS clients which do not
> > > > > honor
> > the
> > > > > > > [Jon] Also agree.  Perhaps 'ttl' should be renamed
> > > > > > > 'alt-server-
> > ttl'.
> > > > > > >
> > > > > > > Please see inline.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Med
> > > > > > >
> > > > > > > > > > > "No,  DNS TTL lifetime does not mean existing
> > > > > > > > > > > session has to be
> > > > > > > > > > disconnected
> > > > > > > > > > > after the TTL expires."
> > > > > > > > > > >
> > > > > > > > > > > TTL** but the validity time of a an alternate server
> > > > > > > > > > > as provided in a DOTS redirect
> > > > > > > > > > signal.
> > > > > > > > > >
> > > > > > > > > > When the server can explicitly re-direct the client,
> > > > > > > > > > why provide the validity time of an alternate server ?
> > > > > > > > >
> > > > > > > > > [Med] Involving the alternate server is one deployment
> > > > > > > > > mode among
> > > > > > > others.
> > > > > > > > https://tools.ietf.org/html/rfc7285#section-
> > 8.5..3).
> > > > > > > >
> > > > > > >
> > > > > > > [Jon] in the general potential overloading case of a
> > > > > > > specific DOTS server, to redirect a DOTS client to an
> > > > > > > alternative DOTS server for a period of
> > > > > > time
> > > > > > > makes sense to me - and then the DOTS client can then come
> > > > > > > back again.  So, to me, [2] is a valid option.
> > > > > > >
> > > > > > >    The 307 (Temporary Redirect) status code indicates that
> > > > > > > the
> > target
> > > > > > >    resource resides temporarily under a different URI and
> > > > > > > the user
> > > > agent
> > > > > > >    redirection to that URI.  Since the redirection can
> > > > > > > change over
> > > > time,
> > > > > > > Supplying the TTL is the only way to master the automatic
> > > > > > > fall back while avoiding contacting the "normal" server
> > > > > > > during the "temporary
> > > > > redirect'.
> > > > > > >
> > > > > > > [Jon] Agreed.
> > > > > >
> > > > > > If TTL expires, DOTS client cannot be re-directed when DDOS
> > > > > > attack is
> > > > active.
> > > > > > If a DOTS client does not honor the TTL value and continues to
> > > > > > use the alternate server, the server should explicitly
> > > > > > re-direct the client and if the client still continues to use
> > > > > > the DOTS server, it should disconnect the (D)TLS session.
> > > > > >
> > > > > > -Tiru
> > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Apr 2018 11:05:54 +0100

Looks good to me also.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 10 April 2018 10:51
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling

Cheers,
-Tiru

> > the mitigation request, 0 value means the client does not get to 
> > send the mitigation request. We may want to clarify that with 0 TTL 
> > value, re-direct applies only for the ongoing mitigation request and 
> > not for other type of requests. Further, too small value will 
> > adversely impact a DOTS client on slow links, e.g. TTL value expires 
> > by the time the mitigation request reaches the DOTS server after
multiple retries.
> > > > > > Envoyé : mardi 10 avril 2018 07:31 À : Jon Shallow; 
> > > > > > > > > > > TTL** but the validity time of a an alternate 
> > > > > > > > > > > server as provided in a DOTS redirect
> > > > > > > > > > signal.
> > > > > > > > > >
> > > > > > If a DOTS client does not honor the TTL value and continues 
> > > > > > to use the alternate server, the server should explicitly 
> > > > > > re-direct the client and if the client still continues to 
> > > > > > use the DOTS server, it should disconnect the (D)TLS session.
> > > > > >
> > > > > > -Tiru
> > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 10 Apr 2018 10:07:18 +0100

Hi Med,

Regards

Jon
-----Original Message-----

Re-,

Cheers,
Med

---

From: <[email-masked]>
Date: Tue, 10 Apr 2018 10:40:48 +0000

Re-,

Thank you both for raising the issue and helping to fix it. 

This one is closed. 

Cheers,
Med

> Envoyé : mardi 10 avril 2018 12:06