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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Thursday, February 28, 2019 6:00 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-,
> 
> 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.

Thanks, update looks good.

-Tiru

> 
> 
> > 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
> > > > > > Comment> the 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