Subject: [Dots] recycling mid/sid values

From: <[email-masked]>
Date: Fri, 3 Aug 2018 14:14:30 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 16:01
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

Yes, this is capturing the spirit of what we have been discussing – thanks.

It is a long paragraph and possibly could logically be broken just before
If
   the DOTS server receives a mitigation request which overlaps with an
   active mitigation request, but both having distinct 'trigger-

It has been brought up before but got lost on the way – what happens when “mid” wraps and 0 is supposed to be greater than 2**32-1 (0xffffffff) for systems that stay up for long long times?

[Med] I didn’t forget this. I discuss it with Tiru offline and our conclusion is this a very very very corner case. The complexity is not about adding that once mid/sid values are exhausted (2*31-1), mid will recycle the value and increment to 0, and so on but in handling out of order request (see below).

“RFC793 TCP 3.3 Sequence numbers” has a way of handling this
  It is essential to remember that the actual sequence number space is
  finite, though very large.  This space ranges from 0 to 2**32 - 1.
  Since the space is finite, all arithmetic dealing with sequence
  numbers must be performed modulo 2**32.  This unsigned arithmetic
  preserves the relationship of sequence numbers as they cycle from
  2**32 - 1 to 0 again.  There are some subtleties to computer modulo
  arithmetic, so great care should be taken in programming the
  comparison of such values.  The symbol "=<" means "less than or equal"
  (modulo 2**32).

[Med] The modulo may be problematic to handle overlapping requests when mid values are close to 2**32-1. New requests will be discarded in favour of old ones; which is not desired.

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Aug 2018 15:39:28 +0100

Hi Med,

In terms of ordering, it is only when the values are numerically separated by more than 2**31 do you have the potential of getting it the wrong way around (when using the TCP sequence number wrapping logic).  The Linux kernel does (for TCP sequence numbers which are unsigned 32 bit)

/*

* The next routines deal with comparing 32 bit unsigned ints 

 * and worry about wraparound (automatic with unsigned arithmetic).

*/     

static inline int before(__u32 seq1, __u32 seq2)

{

        return (__s32)(seq1-seq2) < 0;

}       

#define after(seq2, seq1)       before(seq1, seq2)

So, 1-2147483647 is greater than 0, 2147483647-4294967294 is less than 4294967295, 2147483648-4294967295 is less than 0, 4294967295 is less than 0-2147483647 etc. when doing comparisons.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 03 August 2018 15:15
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Subject: [Dots] recycling mid/sid values

Re-,

Please see inline.

Cheers,

Med

Hi Med,

If

  (modulo 2**32).

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Aug 2018 05:04:51 +0000

Inline [TR]

From: Jon Shallow <[email-masked]>
Sent: Friday, August 3, 2018 8:09 PM
To: [email-masked]; Konda, Tirumaleswar Reddy <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] recycling mid/sid values

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi Med,

/*

So, 1-2147483647 is greater than 0

2147483647-4294967294 is less than 4294967295

[TR] I am not sure if we need such a logic, new protocols like DTLS uses 48-bit sequence number (and 16 byte epoch) and mandates the client to re-handshake prior to allowing the sequence number to wrap. Similarly ESP extends 32-bit sequence number to 64-bit (default is 64-bit in IKEv2), and new security association must be established before the sequence wraps.

We can change mid to uint64, and during peacetime before the ‘mid’ wraps, the DOTS client will delete and re-create the requests again (I don’t see the need to modify sid (it is specific to a DTLS session)).

-Tiru

, 2147483648-4294967295 is less than 0, 4294967295 is less than 0-2147483647 etc. when doing comparisons.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 August 2018 15:15
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Subject: [Dots] recycling mid/sid values

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 3 août 2018 16:01
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Signal Channel WGLC: Trigger-Mitigation

Hi Med,

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Aug 2018 11:01:51 +0100

Hi there, 

See inline Jon>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 August 2018 06:05
To: Jon Shallow; [email-masked]; kaname nishizuka; [email-masked]
Subject: Re: [Dots] recycling mid/sid values

Inline [TR]

  _____  

Hi Med,

/*

*/     

{

}       

 
We can change mid to uint64, and during peacetime before the ‘mid’ wraps, the DOTS client will delete and re-create the requests again
 
Jon> OK, so if the mid has reached half the max size and it is peacetime, then all the trigger-mitigation:false entries are deleted, wait for confirmation of the deletions, and then re-create all the trigger-mitigation:false entries with the mid restarting at 0.  Very minor timing window here if an attack starts.  This does work for me. The mid definition will need to get updated.
4.4.1 Request Mitigation
OLD:
mid: Identifier for the mitigation request represented with an integer. This identifier MUST be unique for each mitigation request bound to the DOTS client, i.e., the 'mid' parameter value in the mitigation request needs to be unique relative to the 'mid' parameter values of active mitigation requests conveyed from the DOTS client to the DOTS server. In order to handle out-of-order delivery of mitigation requests, 'mid' values MUST increase monotonically.
NEW:
mid: Identifier for the mitigation request represented with an integer. This identifier MUST be unique for each mitigation request bound to the DOTS client, i.e., the 'mid' parameter value in the mitigation request needs to be unique relative to the 'mid' parameter values of active mitigation requests conveyed from the DOTS client to the DOTS server.
In order to handle out-of-order delivery of mitigation requests, 'mid' values MUST increase monotonically.  If the ‘mid’ value has reached half the maximum size of a uint32 (2**31) and it is peace-time, then the DOTS client MUST issue a DELETE for each of the mitigation requests with “trigger-mitigation”:false, MUST wait for confirmation response packet of the deletion, and then re-create the mitigation request entry with the ‘mid’ restarting at 0.  The DOTS client may issue the DELETE as a Confirmable (CON) request as an aid to making sure that the old mitigation request with the higher ‘mid’ was deleted.
 
Jon> The above suggested change assumes that for “trigger-mitigation”:false DELETE there is not a “active-but-terminating” period.  Clarity about this will also needed to be added to the DELETE section.
4.4.4 Withdraw a Mitigation
OLD:
If the DOTS server finds the 'mid' parameter value conveyed in the
 DELETE request in its configuration data for the DOTS client, then to
 protect against route or DNS flapping caused by a DOTS client rapidly
 removing a mitigation, and to dampen the effect of oscillating
 attacks, the DOTS server MAY allow mitigation to continue for a
 limited period after acknowledging a DOTS client's withdrawal of a
 mitigation request. During this period, the DOTS server status
 messages SHOULD indicate that mitigation is active but terminating
 (Section 4.4.2).
NEW:
If the DOTS server finds the 'mid' parameter value conveyed in the
 DELETE request in its configuration data for the DOTS client, then to
 protect against route or DNS flapping caused by a DOTS client rapidly
 removing a mitigation, and to dampen the effect of oscillating
 attacks, the DOTS server MAY allow mitigation to continue for a
 limited period after acknowledging a DOTS client's withdrawal of a
 mitigation request. During this period, the DOTS server status
 messages SHOULD indicate that mitigation is active but terminating
 (Section 4.4.2).  If this is an in-active mitigation request with “trigger-mitigation”:false, then there is no active-but-terminating period.
 
Jon> Not convinced we need to go to uint64 – uses up more of the CoAP packet at well as requires all JSON refs to ‘mid’ to be shown as strings and the CBOR mapping tables updates and..  uint32 should be large enough.

(I don’t see the need to modify sid (it is specific to a DTLS session)).

Jon> Agreed.

~Jon

-Tiru

Regards

Jon

Re-,

Please see inline.

Cheers,

Med

Hi Med,

If

  (modulo 2**32).

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 4 Aug 2018 14:36:23 +0000

Please see inline [TR1]

From: Jon Shallow <[email-masked]>
Sent: Saturday, August 4, 2018 3:32 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] recycling mid/sid values

See inline Jon>

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 August 2018 06:05
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] recycling mid/sid values

Inline [TR]

From: Jon Shallow <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 3, 2018 8:09 PM
To: [email-masked]<mailto:[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] recycling mid/sid values

/*

[TR1] Instead of “half the max size” why not use “three-fourth the max size”  ?

4.4.1 Request Mitigation

OLD:

NEW:

In order to handle out-of-order delivery of mitigation requests, 'mid' values MUST increase monotonically.  If the ‘mid’ value has reached half the maximum size of a uint32 (2**31) and it is peace-time, then

[TR1] unit32 is (2**32 – 1)

 the DOTS client MUST issue a DELETE for each of the mitigation requests with “trigger-mitigation”:false, MUST wait for confirmation response packet of the deletion, and then re-create the mitigation request entry with the ‘mid’ restarting at 0.

[TR1] The above text can be simplified. It’s already discussed in section 4.4 that non-confirmable requests will be sent regularly till a response is received.

The DOTS client may issue the DELETE as a Confirmable (CON) request as an aid to making sure that the old mitigation request with the higher ‘mid’ was deleted.

[TR1] I don’t see the need to make an exception to make DELETE a confirmable message (the client anyway will send DELETE at regular intervals till a response is received from the DOTS server).

OLD:

 (Section 4.4.2).

NEW:

[TR1] I don’t think the above line is completely true, even an immediate mitigation request can be inactive because of a conflict and will not transition to active-but-terminating period.

[TR1] Okay

-Tiru

Jon> Agreed.
~Jon

-Tiru

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Aug 2018 16:15:28 +0100

Please see inline Jon1>

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 August 2018 15:36
To: Jon Shallow; [email-masked]; kaname nishizuka; [email-masked]
Subject: Re: [Dots] recycling mid/sid values

Please see inline [TR1]

  _____  

Hi Med,

/*

*/     

{

}       

 

 
Jon1> Fine by me – had to start with something!
 
4.4.1 Request Mitigation
OLD:
 
[TR1] unit32 is (2**32 – 1) 
Jon1> I actually was thinking of the half size value when I wrote that.

[TR1] The above text can be simplified. It’s already discussed in section 4.4 that non-confirmable requests will be sent regularly till a response is received. 
Jon1> My think about the having to wait for the confirmation is that it is unsafe to send a mid with a lower value until the upper mid value has definitely been deleted.

[TR1] I don’t see the need to make an exception to make DELETE a confirmable message (the client anyway will send DELETE at regular intervals till a response is received from the DOTS server). 
Jon> Fair enough.  We just need to make sure that the DELETE completes before moving on.

[TR1] I don’t think the above line is completely true, even an immediate mitigation request can be inactive because of a conflict and will not transition to active-but-terminating period.
Jon1> Agreed – I think we need more clarity about when active-but-terminating period is invoked.  Perhaps state the case(s) (which I think is only one) that it does actually happen rather than list the list of when it does not happen.
~Jon1

[TR1] Okay
 
-Tiru

Jon> Agreed.

~Jon

-Tiru

Regards

Jon

Re-,

Please see inline.

Cheers,

Med

Hi Med,

If

  (modulo 2**32).

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 6 Aug 2018 02:44:58 +0000

Please see inline [TR2]

From: Jon Shallow <[email-masked]>
Sent: Saturday, August 4, 2018 8:45 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; kaname nishizuka <[email-masked]>; [email-masked]
Subject: RE: [Dots] recycling mid/sid values

Please see inline [TR1]

/*

4.4.1 Request Mitigation

OLD:

NEW:

[TR2] Yup.

OLD:

 (Section 4.4.2).

NEW:

[TR2] Yes, we just have 1 scenario, when an active mitigation request is explicitly withdrawn by the DOTS client.

-Tiru

~Jon1

[TR1] Okay

-Tiru

Jon> Agreed.
~Jon

-Tiru

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Regards

Jon

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 05:49:51 +0000

Hi all,

I made this change to the text:

      If the 'mid' value has reached 3/4 of 2**31 and it is peace-time,
      the DOTS client MUST reset 'mid' to 0.  If the DOTS client
      maintains mitigation requests with pre-configured scopes, it MUST
      re-create them with the 'mid' restarting at 0.

It is trivial how to recreate successfully the same requests with new mids. No need to be redundant here.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 6 août 2018 04:45
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; [email-masked]
Objet : RE: [Dots] recycling mid/sid values

Please see inline [TR2]

Please see inline [TR1]

/*

4.4.1 Request Mitigation

OLD:

NEW:

[TR2] Yup.

OLD:

 (Section 4.4.2).

NEW:

-Tiru

~Jon1

[TR1] Okay

-Tiru

Jon> Agreed.
~Jon

-Tiru

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 6 Aug 2018 06:09:03 +0000

Please see inline

From: Dots <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, August 6, 2018 11:20 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; kaname nishizuka <[email-masked]>; [email-masked]
Subject: Re: [Dots] recycling mid/sid values

[TR] unit32 is (2**32 – 1)

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 6 août 2018 04:45
À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] recycling mid/sid values

Please see inline [TR2]

From: Jon Shallow <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, August 4, 2018 8:45 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; kaname nishizuka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] recycling mid/sid values

Please see inline [TR1]

/*

4.4.1 Request Mitigation

OLD:

NEW:

[TR2] Yup.

OLD:

 (Section 4.4.2).

NEW:

-Tiru

~Jon1

[TR1] Okay

-Tiru

Jon> Agreed.
~Jon

-Tiru

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Regards

Jon

---

From: <[email-masked]>
Date: Mon, 6 Aug 2018 12:23:06 +0000

Re-,

To ack and to close this one, the text added to the draft is as follows:

      If the 'mid' value has reached 3/4 of (2**31 - 1) (i.e.,
      3221225471) and it is peace-time, the DOTS client MUST reset 'mid'
     to 0 to handle 'mid' rollover.  If the DOTS client maintains
      mitigation requests with pre-configured scopes, it MUST re-create
      them with the 'mid' restarting at 0.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 6 août 2018 08:09
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; kaname nishizuka; [email-masked]
Objet : RE: [Dots] recycling mid/sid values

Please see inline

Cheers,
Med

Please see inline [TR2]

Please see inline [TR1]

/*

4.4.1 Request Mitigation

OLD:

NEW:

[TR2] Yup.

OLD:

 (Section 4.4.2).

NEW:

-Tiru

~Jon1

[TR1] Okay

-Tiru

Jon> Agreed.
~Jon

-Tiru

Regards

Jon

Re-,

Please see inline.

Cheers,
Med

Hi Med,

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 6 Aug 2018 13:27:15 +0100

Typo – should be (2**32 – 1).

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 06 August 2018 13:23
To: Konda, Tirumaleswar Reddy; Jon Shallow; kaname nishizuka; [email-masked]
Subject: Re: [Dots] recycling mid/sid values

Re-,

Cheers,

Med

Please see inline

  _____  

Hi all, 

Cheers,

Med

Please see inline [TR2]

  _____  

Please see inline Jon1>

Please see inline [TR1]

  _____  

Hi Med,

/*

*/     

{

}       

 

 
 
4.4.1 Request Mitigation
OLD:

 

 
[TR2] Yup.

 
 
-Tiru
 
~Jon1

[TR1] Okay
 
-Tiru

Jon> Agreed.

~Jon

-Tiru

Regards

Jon

Re-,

Please see inline.

Cheers,

Med

Hi Med,

If

  (modulo 2**32).

Regards

Jon