Re: [Dots] AD review of draft-ietf-dots-data-channel-25

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : jeudi 28 février 2019 12:00
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk
> Cc : [e-mail]; [e-mail]
> Objet : RE: AD review of draft-ietf-dots-data-channel-25
> 
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Thursday, February 28, 2019 2:59 PM
> > To: Konda, Tirumaleswar Reddy <[e-mail]>;
> > Benjamin Kaduk <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: AD review of draft-ietf-dots-data-channel-25
> >
> >
> >
> > Re-,
> >
> > I added this note to my local copy:
> >
> >    How a DOTS client synchronizes its configuration with the one
> >    maintained by its DOTS server(s) is implementation-specific.  For
> >    example, a DOTS client can send a GET message before and/or after each
> >    configuration change request.
> 
> The example does not look correct, no need to send GET messages to
> synchronize the configuration during peace time.

[Med] The example was on purpose. We don't specify when and why a client has to check. That is implementation-specific. 

  We need an example to
> discuss the scenario when attack traffic is initiated and client did not
> receive response to the configuration request from the DOTS server.
> I propose the following update:
> For example, a DOTS client can re-establish the disconnected DOTS signal
> channel session after the attack is mitigated and
> sends a GET message before configuration change request.
> 

[Med] I updated the text as follows (we don't need to be exhaustive):

  How a DOTS client synchronizes its configuration with the one
   maintained by its DOTS server(s) is implementation-specific.  For
   example:

   o  a DOTS client can systematically send a GET message before and/or
      after a configuration change request.

   o  a DOTS client can re-establish the disconnected DOTS session after
      an attack is mitigated and sends a GET message before a
      configuration change request.


> Cheers,
> -Tiru
> 
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:[e-mail]]
> > > Envoyé : mercredi 27 février 2019 07:59 À : BOUCADAIR Mohamed TGI/OLN;
> > > Benjamin Kaduk Cc : [e-mail];
> > > [e-mail]
> > > Objet : RE: AD review of draft-ietf-dots-data-channel-25
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > <[e-mail]>
> > > > Sent: Friday, February 15, 2019 5:53 PM
> > > > To: Konda, Tirumaleswar Reddy
> > <[e-mail]>;
> > > > Benjamin Kaduk <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: RE: AD review of draft-ietf-dots-data-channel-25
> > > >
> > > > This email originated from outside of the organization. Do not click
> > > > links
> > > or
> > > > open attachments unless you recognize the sender and know the
> > > > content is
> > > safe.
> > > >
> > > > Hi Tiru,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Konda, Tirumaleswar Reddy
> > > > > [mailto:[e-mail]]
> > > > > Envoyé : vendredi 15 février 2019 12:06 À : BOUCADAIR Mohamed
> > > > > TGI/OLN; Benjamin Kaduk Cc : [e-mail];
> > > > > [e-mail]
> > > > > Objet : RE: AD review of draft-ietf-dots-data-channel-25
> > > > >
> > > > > I am catching up with the discussion, couple of points:
> > > > >
> > > > > 1)
> > > > >       *  If a network resource (DOTS client) detects a potential DDoS
> > > > >          attack from a set of IP addresses, the DOTS client informs
> its
> > > > >          servicing DOTS gateway of all suspect IP addresses that need
> to
> > > > >          be drop- or accept-listed for further investigation.
> > > > >
> > > > > Comment> I don't see why suspect IP addresses will be accept-listed ?
> > > > >                     We may want to remove "or accept-listed" from
> > > > > the above line.
> > > > >
> > > >
> > > > [Med] Ack.
> > > >
> > > > > [Med] The dots client will know if its request is successfully
> delivered.
> > > > > When an attack is ongoing, the dots client should not use it data
> > > > > channel because it is likely to be perturbed.
> > > > >
> > > > > Comment> If the HTTP response from the server did not reach the
> > > > > Comment> client
> > > > > because of a volumetric attack saturating the incoming the link,
> > > > > the DOTS client will not know whether the configuration is
> > > > > successfully updated or not. After the attack is mitigated, the
> > > > > client will have to re-establish the TLS session and retrieve the
> > > > > configuration to check if its last request was successfully
> > > > > applied or not before updating the configuration.
> > > > >
> > > >
> > > > [Med] Agree. Still, how the client syncs its config with the one
> > > > maintained
> > > by
> > > > the server is implementation-specific. A client can send a GET
> > > > before
> > > and/or
> > > > after a configuration change request, in regular intervals, after
> > > > attack mitigation, etc.
> > >
> > > Adding a Implementation Note looks useful to me.
> > >
> > > -Tiru
> > >
> > > >
> > > > > Cheers,
> > > > > -Tiru