Re: [Dots] Yangdoctors early review of draft-ietf-dots-telemetry-09

[[e-mail]]

Hi Jan,

 

Further to what Med has said as a clarification for errors server side when sending back a response assuming it is not a server crash.

 

if the mitigation was accepted (all sanity checks must have passed at this point) by the DOTS server, but then the passing over to the DOTS mitigator choked for whatever reason and could not handle it, the following sequence happens.

 

The server would initially have sent back an “attack-mitigation-in-progress” in response to the mitigation request, but never moves on to updating the status to “attack-successfully-mitigated” which happens when the mitigator puts the DDoS mitigation into action and indicates this back to the  DOTS server.  See  RFC8782 : Figure 15: Notifications of Attack Mitigation Status.  The DOTS server would then go on to setting the status to “attack-mitigation-withdrawn” (RFC8782 : Table 3: Values of 'status' Parameter).

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of [e-mail]
Sent: 08 July 2020 10:19
To: Jan Lindblad
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Dots] Yangdoctors early review of draft-ietf-dots-telemetry-09

 

Jan, 

 

Some clarifications about this one: 

 

+ If a server has started sending back a response to a client request, but then hits an internal error, and is unable to filfil the request, what should it do? Is closing the connection a reasonable response?

[Med] We don’t have text as this is implementation-specific. That’s said I expect implementations to maintain the session alive as we are dealing with DDoS attack mitigation. 

 

I thought that you were asking for a case where the server has accepted for example a (mitigation) request but then encounters an error. That case is implementation-specific. 

 

FWIW, we do have the following: 

 

·         If the server crashes, the connection will be closed. This will be detected by the client thanks to the use of heartbeats. The client will then re-establish the signal session.

·         For errors on the server side we do have the following: 

 

   “The error Response Code 5.03 (Service Unavailable) is

   returned if the DOTS server has erred or is incapable of performing

   the mitigation.  As specified in [ <https://tools.ietf.org/html/rfc7252> RFC7252], 5.03 uses Max-Age Option

   to indicate the number of seconds after which to retry."

 

Implementations can send 5.00, but how the client will react to the error code is implementation-specific.  

 

Cheers,

Med

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.