Subject: [Dots] Overlapping mitigation requests from a DOTS client

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 1 Nov 2017 13:29:56 +0000

In the DOTS signal channel draft, if two mitigation requests have overlapping mitigations scopes, then the overlapped lower number mitigation-id is automatically deleted by the DOTS server.

Jon's DOTS server implementation uses the above approach but Kaname's implementation maintains both the mitigation requests, and the DOTS server automatically falls back to use the lower number mitigation-id after the higher number mitigation-id is deleted by the DOTS client. The disadvantage of the latter approach is, the DOTS server and client could end-up maintaining a long list of overlapping mitigation requests and looks error-prone.

This issue was raised in the virtual interim meeting https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/minutes-interim-2017-dots-03-201710021000/ and tracked in https://github.com/dotswg/dots-signal-channel/issues/2

I would like to start this thread is to discuss the pros and cons of both mechanisms, to help decide if the current behavior can be retained or needs to be modified.

-Tiru

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 01 Nov 2017 21:04:09 +0700

On 1 Nov 2017, at 20:29, Konda, Tirumaleswar Reddy wrote:

> In the DOTS signal channel draft, if two mitigation requests have 
> overlapping mitigations scopes, then the overlapped lower number 
> mitigation-id is automatically deleted by the DOTS server.

My view is that resolving mitigation scope overlaps are out of scope for 
DOTS itself.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 1 Nov 2017 14:29:04 -0000

In one sense, I agree with Roland - but what is an overlap has been defined
though.

I have always struggled with what happens when a mitigation id hits the
maximum value and wraps around to what will be a lower number compared to
existing mitigation ids.  If the DOTS client restarts, does the mitigation
id get reset, or is the last mitigation id used get remembered and things
move on from there etc.?

If we remove the requirement for overlapping checks, then the complete list
of mitigation requests may fill up RAM or a database - especially of a DOTS
client goes 'rogue'.

I think having a complete rollback of mitigation requests is a bit excessive
- entries in the middle of the list can be deleted as well as the last or
first one.  Programmatically this can be done, but could get a bit messy -
especially when deciding whether requests overlap or not across the entire
list.  Best case for me would be to retain current and previous mitigations.

To me, the signalling needs to be as simple as possible, reducing the
possibility of errors during attack time where requests may get dropped,
appear in the wrong order etc.

If a DOTS client elects to go back to the previous mitigation request (lower
id) by deleting the current request, either the DOTS server has to remember
the previous request, or the DOTS client issues a new mitigation requests
with the previous mitigation's characteristics.  I think I prefer the DOTS
client issuing it as a new mitigation request - otherwise the client will
need to delete the previous mitigation request at some point.

... but all the above still does not answer what happens when mitigation ids
wrap back to 0!

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Roland Dobbins
Sent: 01 November 2017 14:04
To: [email-masked]
Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 Nov 2017 10:00:47 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Wednesday, November 1, 2017 7:59 PM
> To: 'Roland Dobbins' <[email-masked]>; [email-masked]
> maximum value and wraps around to what will be a lower number
> compared to existing mitigation ids.  If the DOTS client restarts, does the
> mitigation id get reset, or is the last mitigation id used get remembered and
> things move on from there etc.?

After restart, DOTS client can either retrieve the previously conveyed and active mitigation requests from the DOTS server or 
has to store the last mitigation-id number in a persistent storage. 

> of mitigation requests may fill up RAM or a database - especially of a DOTS

Agreed. 

> - entries in the middle of the list can be deleted as well as the last or first one.
> Programmatically this can be done, but could get a bit messy - especially
> when deciding whether requests overlap or not across the entire list.  Best
> case for me would be to retain current and previous mitigations.
> 
> with the previous mitigation's characteristics.  I think I prefer the DOTS client
> issuing it as a new mitigation request - otherwise the client will need to
> delete the previous mitigation request at some point.

Yes, this approach looks good.

> wrap back to 0 !

I don't see a problem. Mitigation-id can take up to  2**32 values before rolling back, mitigation-id typically will have a finite lifetime (unless indefinite lifetime is used) and PUT allows the client to re-use any 
existing mitigation-id and overwrite the mitigation request with updated mitigation scopes.   

-Tiru

> My view is that resolving mitigation scope overlaps are out of scope for DOTS
> itself.
>

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 2 Nov 2017 10:29:56 -0000

Hi Tiru,

>> 
>> ... but all the above still does not answer what happens when 
>> mitigation ids wrap back to 0 !

> I don't see a problem. Mitigation-id can take up to  2**32 values before
rolling back, mitigation-id typically will have a > > finite lifetime
(unless indefinite lifetime is used) and PUT allows the client to re-use any

> existing mitigation-id and overwrite the mitigation request with updated
mitigation scopes.   

[5.4.1.  Requesting mitigation] States

"  For a mitigation request to continue beyond the initial negotiated
   lifetime, the DOTS client need to refresh the current mitigation
   request by sending a new PUT request.  The PUT request MUST use the
   same 'mitigation-id' value, and MUST repeat all the other parameters
   as sent in the original mitigation request apart from a possible
   change to the lifetime parameter value."

So, my DOTS server currently rejects any PUT with a mitigation id that
already exists that then has a mitigation scope change.

You could user a lower mitigation id that is no longer in use to update a
mitigation scope, but if there is a scope overlap, then that too will get
rejected / ignored.  Some of the DOTS agents are likely to be running for
years, but I guess that even with a new mitigation id per second, that is
about 68 years' worth, so we should be OK!

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 02 November 2017 10:01
To: Jon Shallow; 'Roland Dobbins'; [email-masked]
Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client

> In one sense, I agree with Roland - but what is an overlap has been 
> defined though.
> 
> I have always struggled with what happens when a mitigation id hits 
> the maximum value and wraps around to what will be a lower number 
> compared to existing mitigation ids.  If the DOTS client restarts, 
> does the mitigation id get reset, or is the last mitigation id used 
> get remembered and things move on from there etc.?

After restart, DOTS client can either retrieve the previously conveyed and
active mitigation requests from the DOTS server or has to store the last
mitigation-id number in a persistent storage. 

> 
> If we remove the requirement for overlapping checks, then the complete 
> list of mitigation requests may fill up RAM or a database - especially 
> of a DOTS client goes 'rogue'.

Agreed. 

> - entries in the middle of the list can be deleted as well as the last or
first one.
> Programmatically this can be done, but could get a bit messy - 
> especially when deciding whether requests overlap or not across the 
> entire list.  Best case for me would be to retain current and previous
mitigations.
> possibility of errors during attack time where requests may get 
> dropped, appear in the wrong order etc.
> 
> id) by deleting the current request, either the DOTS server has to 
> remember the previous request, or the DOTS client issues a new 
> mitigation requests with the previous mitigation's characteristics.  I 
> think I prefer the DOTS client issuing it as a new mitigation request 
> - otherwise the client will need to delete the previous mitigation request
at some point.

> 
> ... but all the above still does not answer what happens when 
> mitigation ids wrap back to 0 !

I don't see a problem. Mitigation-id can take up to  2**32 values before
rolling back, mitigation-id typically will have a finite lifetime (unless
indefinite lifetime is used) and PUT allows the client to re-use any 
existing mitigation-id and overwrite the mitigation request with updated
mitigation scopes.   

-Tiru

> My view is that resolving mitigation scope overlaps are out of scope 
> for DOTS itself.
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 Nov 2017 10:41:01 +0000

> From: Jon Shallow [mailto:[email-masked]]
> Sent: Thursday, November 2, 2017 4:00 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Roland Dobbins <[email-masked]>; [email-masked]
> Subject: RE: [Dots] Overlapping mitigation requests from a DOTS client
> 
> Hi Tiru,
> 
> >>
> rolling back, mitigation-id typically will have a > > finite lifetime (unless
> So, my DOTS server currently rejects any PUT with a mitigation id that already
> exists that then has a mitigation scope change.

I don't think this behavior is correct, PUT allows the DOTS client to change the mitigation scope for a mitigation-id. 
"MUST" is used in the above line only to suggest that mitigation scope must not be changed when only refreshing the lifetime of the mitigation request. 

> years, but I guess that even with a new mitigation id per second, that is about
> 68 years' worth, so we should be OK!

:) 

-Tiru

> From: Dots [mailto: [email-masked]] On Behalf Of Konda,
> Tirumaleswar Reddy
> rolling back, mitigation-id typically will have a finite lifetime (unless indefinite
> lifetime is used) and PUT allows the client to re-use any existing mitigation-id
> and overwrite the mitigation request with updated
> mitigation scopes.
> 
> -Tiru
> 
> >
> > Regards
> >
> > Jon
> >

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 2 Nov 2017 11:25:00 -0000

Hi Tiru,

I am having programmatic challenges here with your comment.

Case 1: PUT request for same mitigation-id is identical (apart from maybe
lifetime)

Mitigation is refreshed for another lifetime  seconds(or infinite if -1).

Case 2: PUT request for same mitigation-id has a new mitigation scope -
lifetime may or may not be different

Old mitigation is overwritten with new scope parameters - is the mitigation
lifetime refreshed for another lifetime seconds, or the remaining time of
the mitigation left unchanged?

If the mitigation lifetime is refreshed, then why do we need Case 1:  with a
MUST?

There is a second potential issue with Case 2 - what if there is a later
mitigation-id also active - no overlap conflicts with original scope, but
then has an overlap conflict with the replacement scope - do we auto-delete
the mitigation-id that was just updated?

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 02 November 2017 10:41
To: Jon Shallow; Roland Dobbins; [email-masked]
Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client

> already exists that then has a mitigation scope change.

I don't think this behavior is correct, PUT allows the DOTS client to change
the mitigation scope for a mitigation-id. 
"MUST" is used in the above line only to suggest that mitigation scope must
not be changed when only refreshing the lifetime of the mitigation request. 

> 
> You could user a lower mitigation id that is no longer in use to 
> update a mitigation scope, but if there is a scope overlap, then that 
> too will get rejected / ignored.  Some of the DOTS agents are likely 
> to be running for years, but I guess that even with a new mitigation 
> id per second, that is about

:) 

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 Nov 2017 15:36:49 +0000

> Sent: Thursday, November 2, 2017 4:55 PM
> lifetime refreshed for another lifetime seconds, or the remaining time of the
> mitigation left unchanged?
> 

PUT allows the resources to be updated (see https://tools.ietf.org/html/rfc7252#section-5.8.3), so all the mitigation scope parameters have to be re-conveyed 
in the mitigation request to refresh the mitigation lifetime. I don't think DOTS should lose the flexibility PUT method provides.

> mitigation-id also active - no overlap conflicts with original scope, but then
> has an overlap conflict with the replacement scope - do we auto-delete the
> mitigation-id that was just updated ?

For case 2, the DOTS client should either over-write the later active mitigation-id or create a new mitigation-id whose value is higher 
than the current active mitigation-id.

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 2 Nov 2017 16:38:48 -0000

Hi Tiru,

"PUT allows the resources to be updated (see
https://tools.ietf.org/html/rfc7252#section-5.8.3), so all the mitigation
scope parameters have to be re-conveyed in the mitigation request to refresh
the mitigation lifetime. I don't think DOTS should lose the flexibility PUT
method provides."

I agree about not losing flexibility.

However, if the mitigation lifetime is only extended if there is an exact
match on all the other scope parameters - is this the scope parameters
before the PUT updates the mitigation scope, or after the PUT updates the
mitigation scope?

If the PUT update sends less parameters - are the non-referenced parameters
that were in the previous PUT request  to be left there or deleted?

I need to know what to keep to look for an exact match to allow lifetime to
be extended because of the MUST whenever any PUT updated the current
mitigation scope.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 02 November 2017 15:37
To: Jon Shallow; Roland Dobbins; [email-masked]
Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client

> Case 2: PUT request for same mitigation-id has a new mitigation scope 
> - lifetime may or may not be different
> 
> Old mitigation is overwritten with new scope parameters - is the 
> mitigation lifetime refreshed for another lifetime seconds, or the 
> remaining time of the mitigation left unchanged?
> 
> If the mitigation lifetime is refreshed, then why do we need Case 1:  
> with a MUST?

PUT allows the resources to be updated (see
https://tools.ietf.org/html/rfc7252#section-5.8.3), so all the mitigation
scope parameters have to be re-conveyed in the mitigation request to refresh
the mitigation lifetime. I don't think DOTS should lose the flexibility PUT
method provides.

> 
> There is a second potential issue with Case 2 - what if there is a 
> later mitigation-id also active - no overlap conflicts with original 
> scope, but then has an overlap conflict with the replacement scope - 
> do we auto-delete the mitigation-id that was just updated ?

For case 2, the DOTS client should either over-write the later active
mitigation-id or create a new mitigation-id whose value is higher than the
current active mitigation-id.

-Tiru

> > rolling back, mitigation-id typically will have a > > finite 
> > lifetime (unless indefinite lifetime is used) and PUT allows the 
> > client to re-use any
> >
> > So, my DOTS server currently rejects any PUT with a mitigation id 
> > that already exists that then has a mitigation scope change.
> 
> I don't think this behavior is correct, PUT allows the DOTS client to 
> change the mitigation scope for a mitigation-id.
> "MUST" is used in the above line only to suggest that mitigation scope 
> must not be changed when only refreshing the lifetime of the mitigation
request.
> > update a mitigation scope, but if there is a scope overlap, then 
> > that too will get rejected / ignored.  Some of the DOTS agents are 
> > likely to be running for years, but I guess that even with a new 
> > mitigation id per second, that is about

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 Nov 2017 08:46:01 +0000

> Sent: Thursday, November 2, 2017 10:09 PM
> https://tools.ietf.org/html/rfc7252#section-5.8.3), so all the mitigation scope
> parameters have to be re-conveyed in the mitigation request to refresh the
> mitigation lifetime. I don't think DOTS should lose the flexibility PUT method
> provides."
> 
> However, if the mitigation lifetime is only extended if there is an exact match
> on all the other scope parameters - is this the scope parameters before the
> PUT updates the mitigation scope, or after the PUT updates the mitigation
> scope?
> 
> If the PUT update sends less parameters - are the non-referenced
> parameters that were in the previous PUT request  to be left there or deleted?

PUT replaces the mitigation request, so non-referenced parameters will be deleted. 

-Tiru

> https://tools.ietf.org/html/rfc7252#section-5.8.3), so all the mitigation scope
> parameters have to be re-conveyed in the mitigation request to refresh the
> mitigation lifetime. I don't think DOTS should lose the flexibility PUT method
> provides.
> 
> >