Subject: Re: [Dots] DOTS gateway loop handling

From: <[email-masked]>
Date: Mon, 8 Jan 2018 13:37:09 +0000

Hi Tiru, Jon, all,

Please find below a tentative text to cover this issue:

==

   hop-limit:  This attribute is used to detect and prevent infinite

      loops.  This attribute is typically inserted by a DOTS gateway.

      Each intermediate DOTS agent involved in the handling of a DOTS

      message MUST decrement the hop-limit value by 1 prior to

      forwarding upstream.  DOTS messages MUST NOT be forwarded if the

      value of hop-limit is set to '0' after decrement.  Messages that

      cannot be forwarded because of exhausted hop-limit SHOULD be

      logged.

      The initial hop-limit value SHOULD be configurable.  If no initial

      value is explicitly provided, the default initial hop-limit value

      of 16 (32/64?) MUST be used.

      Because forwarding errors may occur if inadequate hop-limit values

      are used, DOTS agents at the boundaries of an administrative

      domain MAY be instructed to rewrite the value of hop-limit carried

      in received messages (that is, ignore the value of hop-limit

      received in a message).

      This is an optional attribute.
===

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : vendredi 22 décembre 2017 11:32
À : Jon Shallow; [email-masked]
Objet : Re: [Dots] DOTS gateway loop handling

Yes, I meant as CBOR and JSON parameters.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, December 22, 2017 4:00 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] DOTS gateway loop handling

Hi Tiru,

I'm not sure that we can necessarily support this as a Header, but certainly as a parameter in the CBOR / JSON

I think the most likely scenario for this loop to happen is if DNS is not working as expected.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 22 December 2017 10:24
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS gateway loop handling

Good point, both drafts can use a mechanism similar to the one discussed in https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header).

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 2:53 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] DOTS gateway loop handling

Hi WG,

While there never should be a loop in DOTS traffic going via DOTS gateways, if there is a mis-configuration a request can end up getting bounced between a set of (not necessarily adjacent) DOTS gateways.

We need to make sure that this loop is broken - possibly by using a mechanism similar to TTL in IP packets.

If we agree that loops need to get broken, this "feature" needs to get added into both the signal and data channels.

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 8 Jan 2018 14:09:42 +0000

Hi Med,

Looks good, an error response is required to identify the request has not reached the final DOTS server.

Cheers,
-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] DOTS gateway loop handling

Hi Tiru, Jon, all,

==

      logged.

      received in a message).

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : vendredi 22 décembre 2017 11:32
À : Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] DOTS gateway loop handling

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi WG,

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 8 Jan 2018 14:29:27 -0000

Hi Med,

Agree with Titu’s comment.

We do however have “MUST decrement” and “This is an optional parameter”.  I
then we need to modify the MUST component from

MUST decrement the hop-limit value by 1 prior to

      forwarding upstream. 

To

MUST decrement the hop-limit value by 1 prior to

      forwarding upstream if this parameter exists. 

I do however think that this should be a required parameter for a DOTS
gateway, and to insert if it does not already exist (i.e. insert if missing,
decrement if existing) to prevent the possibility of any looping.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 08 January 2018 14:10
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] DOTS gateway loop handling

Hi Med,

Looks good, an error response is required to identify the request has not
reached the final DOTS server.

Cheers,

-Tiru

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon
Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] DOTS gateway loop handling

Hi Tiru, Jon, all, 

==

 

===

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
Reddy
Envoyé : vendredi 22 décembre 2017 11:32
À : Jon Shallow; [email-masked]
Objet : Re: [Dots] DOTS gateway loop handling

-Tiru

From: Jon Shallow [mailto:[email-masked]] 
Sent: Friday, December 22, 2017 4:00 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]
Subject: RE: [Dots] DOTS gateway loop handling

Hi Tiru,

I’m not sure that we can necessarily support this as a Header, but certainly
as a parameter in the CBOR / JSON

I think the most likely scenario for this loop to happen is if DNS is not
working as expected.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 22 December 2017 10:24
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] DOTS gateway loop handling

Good point, both drafts can use a mechanism similar to the one discussed in
https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header).

-Tiru

To: [email-masked]

Hi WG,

While there never should be a loop in DOTS traffic going via DOTS gateways,
if there is a mis-configuration a request can end up getting bounced between
a set of (not necessarily adjacent) DOTS gateways.

We need to make sure that this loop is broken – possibly by using a
mechanism similar to TTL in IP packets.

If we agree that loops need to get broken, this “feature” needs to get added
into both the signal and data channels.

Regards

Jon

---

From: <[email-masked]>
Date: Mon, 8 Jan 2018 14:43:35 +0000

Re-,

A new error code would be required for this (e.g., 5.xy "hop limit reached").

Then, we do need to answer these questions:

-    What a client is supposed to do when such error is received?

-    Should the DOTS gateway that is responsible for setting the hop-limit tracks the error messages so that it can adjust the setting in forthcoming messages? Or we should be silent about this?

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : lundi 8 janvier 2018 15:10
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : Re: [Dots] DOTS gateway loop handling

Hi Med,

Cheers,
-Tiru

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] DOTS gateway loop handling

Hi Tiru, Jon, all,

==

      logged.

      received in a message).

Cheers,
Med

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi WG,

Regards

Jon

---

From: <[email-masked]>
Date: Mon, 8 Jan 2018 14:53:58 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : lundi 8 janvier 2018 15:29
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] DOTS gateway loop handling

Hi Med,

Agree with Titu's comment.

We do however have "MUST decrement" and "This is an optional parameter".  I then we need to modify the MUST component from

To

[Med] Works for me.

I do however think that this should be a required parameter for a DOTS gateway, and to insert if it does not already exist (i.e. insert if missing, decrement if existing) to prevent the possibility of any looping.
[Med] The current text covers the following cases:

-    Insert by the gw

-    Trust + decrement

-    To not trust + rewrite

Would it be helpful of we add this NEW text?

"DOTS gateways SHOULD support this attribute"

Regards

Jon
From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 08 January 2018 14:10
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS gateway loop handling

Hi Med,

Cheers,
-Tiru

Hi Tiru, Jon, all,

==

      logged.

      received in a message).

Cheers,
Med

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi WG,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 8 Jan 2018 14:57:04 +0000

Hop-limit is required for both DOTS signal and data channels. The default value of 16 looks large enough to indicate looping, DOTS client cannot do anything but the on-path DOTS gateway administrators can look the misconfiguration problem once the 5.xy error is received. On reflection, the misconfiguration though looks likely unlikely, it has to happen both at DNS and trust anchor database (Is it really required ?) !

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 8, 2018 8:14 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] DOTS gateway loop handling

Re-,

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : lundi 8 janvier 2018 15:10
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] DOTS gateway loop handling

Hi Med,

Cheers,
-Tiru

Hi Tiru, Jon, all,

==

      logged.

      received in a message).

Cheers,
Med

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi WG,

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 9 Jan 2018 10:29:14 -0000

While I agree that this “loop” is very unlikely to occur, I still think that
we have to defend against this edge case which could be used as an attack
vector against DOTS.

In answer to Med’s questions.

1)      I think a default hop count of 16 is fine, but could make it 32 so
that it is larger than any likely hop count.  If it is to be configurable,
then it should not be less than 16.

2)      If a client gets back an error, there is a either a loop, or the
“hop-limit count” is insufficient.  The client should record / report the
failure – and possibly the DOTS gateway that inserted the first occurrence
of hop-limit as there is either a network issue, or a misconfiguration
issue.

3)      I do not think that the inserting DOTS gateway should auto change
the “hop-limit count” based on a failure – as there could be an upstream
loop.

If there is a loop failure, the DOTS client will not get back a response
(using UDP or TCP) if no diagnostic message is sent back, so will have to
handle the “no response” condition anyway.  Having a diagnostic 5.xy is a
helpful addition.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 08 January 2018 14:57
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] DOTS gateway loop handling

Hop-limit is required for both DOTS signal and data channels. The default
value of 16 looks large enough to indicate looping, DOTS client cannot do
anything but the on-path DOTS gateway administrators can look the
misconfiguration problem once the 5.xy error is received. On reflection, the
misconfiguration though looks likely unlikely, it has to happen both at DNS
and trust anchor database (Is it really required ?) !

-Tiru

Re-,

A new error code would be required for this (e.g., 5.xy “hop limit
reached”). 

-    Should the DOTS gateway that is responsible for setting the hop-limit
tracks the error messages so that it can adjust the setting in forthcoming
messages? Or we should be silent about this?   

Cheers,

Med

Hi Med,

Cheers,

-Tiru

Hi Tiru, Jon, all, 

==

 

===

Cheers,

Med

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi WG,

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 9 Jan 2018 12:34:36 +0000

Jon,

I don't think that we can mandate a minimum value. It is up to entity deploying a GW to decide whether the default value or another one (even less than 16) has to be used. We should not interfere with deployment decisions, IMHO.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 9 janvier 2018 11:29
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] DOTS gateway loop handling

While I agree that this "loop" is very unlikely to occur, I still think that we have to defend against this edge case which could be used as an attack vector against DOTS.

In answer to Med's questions.

1)      I think a default hop count of 16 is fine, but could make it 32 so that it is larger than any likely hop count.  If it is to be configurable, then it should not be less than 16.

2)      If a client gets back an error, there is a either a loop, or the "hop-limit count" is insufficient.  The client should record / report the failure - and possibly the DOTS gateway that inserted the first occurrence of hop-limit as there is either a network issue, or a misconfiguration issue.

3)      I do not think that the inserting DOTS gateway should auto change the "hop-limit count" based on a failure - as there could be an upstream loop.

If there is a loop failure, the DOTS client will not get back a response (using UDP or TCP) if no diagnostic message is sent back, so will have to handle the "no response" condition anyway.  Having a diagnostic 5.xy is a helpful addition.

Regards

Jon

-Tiru

Re-,

Cheers,
Med

Hi Med,

Cheers,
-Tiru

Hi Tiru, Jon, all,

==

      logged.

      received in a message).

Cheers,
Med

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi WG,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 9 Jan 2018 13:21:44 +0000

Hi Jon,

Please explain how attackers can create this attack vector against DOTS ?

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, January 9, 2018 3:59 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dots] DOTS gateway loop handling

Regards

Jon

-Tiru

Re-,

Cheers,
Med

Hi Med,

Cheers,
-Tiru

Hi Tiru, Jon, all,

==

      logged.

      received in a message).

Cheers,
Med

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi WG,

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 9 Jan 2018 13:34:34 -0000

Hi Tiru,

Poisoning a DNS server entry of an upstream DOTS server to cause a DOTS
gateway server-facing-side to either talk to the IP of its
client-facing-side, or possibly the IP of a client-facing-side of a previous
DOTS gateway would to me be a starting point.  The DOTS peer trust
relationships should break this loop though unless this was not getting
properly enforced (in, say a client-domain).

Otherwise, a misconfiguration at set up time could cause this loop.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 09 January 2018 13:22
To: Jon Shallow; [email-masked]; [email-masked]
Subject: Re: [Dots] DOTS gateway loop handling

Hi Jon,

-Tiru

[email-masked]; [email-masked]

Regards

Jon

-Tiru

Re-,

Cheers,

Med

Hi Med,

Cheers,

-Tiru

Hi Tiru, Jon, all, 

==

 

===

Cheers,

Med

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi WG,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 9 Jan 2018 13:45:57 +0000

Hi Jon,

I don't see an successful attack, DNS cache poisoning will be detected the by the DOTS gateway by validating the peer DOTS agent identity.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Tuesday, January 9, 2018 7:05 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] DOTS gateway loop handling

Hi Tiru,

Poisoning a DNS server entry of an upstream DOTS server to cause a DOTS gateway server-facing-side to either talk to the IP of its client-facing-side, or possibly the IP of a client-facing-side of a previous DOTS gateway would to me be a starting point.  The DOTS peer trust relationships should break this loop though unless this was not getting properly enforced (in, say a client-domain).

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 09 January 2018 13:22
To: Jon Shallow; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS gateway loop handling

Hi Jon,

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, January 9, 2018 3:59 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS gateway loop handling

Regards

Jon

-Tiru

Re-,

Cheers,
Med

Hi Med,

Cheers,
-Tiru

Hi Tiru, Jon, all,

==

      logged.

      received in a message).

Cheers,
Med

-Tiru

Hi Tiru,

Regards

Jon

-Tiru

Hi WG,

Regards

Jon