Subject: [core] 🔔 WGLC of draft-ietf-core-hop-limit-03.txt

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Jun 2019 20:17:22 +0200

During the last interim, we said we want to run a Working Group last call on

https://tools.ietf.org/html/draft-ietf-core-hop-limit-03

When we discussed this at the interim, we said that, apart from the overall state of the document, we would like to address two questions in this WGLC:

(1) With a way to perform proxy loop mitigation now available, what is our recommendation for usage?  Is this something that is (a) specific to DOTS, something that (b) it would now be reasonable to expect a proxy to add, or (c) something that every CoAP implementation should do?  (At the interim, we were leaning towards (b).)

(2) The HTTP world has a concurrent document addressing the same issue, 

https://tools.ietf.org/html/rfc8586

The technical approach is different here (based on leaving breadcrumbs in the requests), so it acts as a true loop prevention mechanism, not just mitigation.  It also is more expensive, adding dozens of bytes to each request passing a proxy.  Still, we want to make sure the difference in approaches is well justified.

The WGLC will end in exactly 336 hours so we can discuss the outcome at the CoRE WG Interim meeting on 2019-06-26.  Please indicate your position in a message to the CoRE mailing list ([email-masked]) or, exceptionally, to the chairs ([email-masked]).

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 24 Jun 2019 17:42:12 +0200

I've performed a quick review of draft-ietf-core-hop-limit-03:

1. "More and more applications are using Constrained Application
Protocol" - ...are using *the* Constrained Application Protocol...

1. "a distributed denial-of-service (DDoS) attack signaling protocol
seeking for help" - ...protocol *for* seeking for help...?

1. "When multiple proxies are involved, infinite forwarding loops may
be experienced." - It might be useful to spell out why such forwarding
loops might exist.

1. "which is inserted in particular by on-path proxies" - This is hard
to read. (It took me a few reads to notice that there's no word
missing after "in particular"...)

3. "Therefore, any message carrying multiple Hop-Limit options MUST be
rejected using 4.00 (Bad Request) error message." - Better to
reference RFC 7252, which specifies in detail what to do with an
option that doesn't have the right number of occurrences [1].

3. "The value of the Hop-Limit option is encoded as an 8-bit unsigned
integer" - Remove "8-bit". The range of a CoAP uint is not measured in
bits.

3. "The initial Hop-Limit value SHOULD be configurable." - Is it
really a protocol violation if my implementation does not provide a
configuration option for this?

3. "the default initial Hop-Limit value of 16 MUST be used" - Do we
have any actual insights to guide the choice for a default of 16 and
maximum of 255?

3. "A CoAP proxy which understands the Hop-Limit option MUST NOT use a
stored TBA1 (Hop Limit Reached) error response unless..." - Do we need
to say something about non-"Hop Limit Reached" responses here? E.g.,
when there's a cached 2.05 (Content) response and a request with a
lower hop limit is received, the last hop might not be reachable
anymore. On the other hand, if there's a cached 2.05 (Content)
response, then there's clearly no loop, which is what we're trying to
detect here.

3. "To ease debugging and troubleshooting, the CoAP proxy which
detects a loop SHOULD include its information ... Each intermediate
proxy involved in relaying a TBA1 (Hop Limit Reached) error message
SHOULD prepend its own information" - Is it really a protocol
violation if I want to configure my proxy not to include any
information?

3. "That information MUST NOT include any space character." - Since a
diagnostic payload is intended for debugging, it seems weird to make
any requirements on the formatting. Diagnostic information without any
space characters is probably very hard to read.

3. "Each intermediate proxy involved in relaying a TBA1 (Hop Limit
Reached) error message SHOULD prepend its own information" - It might
be worth pointing out that at some point the diagnostic message might
become so large that Blockwise Transfers [2] are needed.

> (1) With a way to perform proxy loop mitigation now available, what is our recommendation for usage?  Is this something that is (a) specific to DOTS, something that (b) it would now be reasonable t…

I think it would be reasonable to expect every proxy to implement this
and have it enabled by default.

> The technical approach is different here (based on leaving breadcrumbs in the requests), so it acts as a true loop prevention mechanism, not just mitigation.  It also is more expensive, adding doze…

Maybe if there aren't too many proxies, then adding one or two dozen
bytes isn't that expensive?

We should check how to do HTTP/CoAP and CoAP/HTTP Mapping when a
Hop-Limit option/CDN-Loop header field is present.

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-5.4.5
[2] https://tools.ietf.org/html/rfc7959

---

From: <[email-masked]>
Date: Tue, 25 Jun 2019 15:13:20 +0000

Hi Klaus, 

Thank you for the comments.

Please see inline. 

Cheers,
Med/Tiru/Jon

> -----Message d'origine-----
> De : core [mailto:[email-masked]] De la part de Klaus Hartke
> Envoyé : lundi 24 juin 2019 17:42
> À : Carsten Bormann
> Cc : core
> Objet : Re: [core] 🔔 WGLC of draft-ietf-core-hop-limit-03.txt
> 

[Med] OK.

> seeking for help" - ...protocol *for* seeking for help...?

[Med] OK

> be experienced." - It might be useful to spell out why such forwarding

[Med] Updated. This is basically about misconfiguration, policy conflicts, etc. 

> missing after "in particular"...)

[Med] Fixed. 

> option that doesn't have the right number of occurrences [1].

[Med] Makes sense. Fixed. 

> integer" - Remove "8-bit". The range of a CoAP uint is not measured in

[Med] OK

> configuration option for this?

[Med] No, it is not a protocol violation (that is the reason for using "SHOULD" and not "MUST"). 

> have any actual insights to guide the choice for a default of 16 and

[Med] We went for 255 as a max to be aligned with TTL (ipv4, mpls) and Hop Limit (ipv6) with the assumption that every intermediate node embeds a CoAP proxy. 

The main rationale for picking 16 is what is currently depicted in the draft: 

   "This value is chosen to be sufficiently large to
   guarantee that a CoAP request would not be dropped in networks when
   there were no loops, but not so large as to consume CoAP proxy
   resources when a loop does occur.  Lower values should be used with
   caution and only in networks where topologies are known by the CoAP
   client (or proxy) inserting the Hop-Limit option."

> response, then there's clearly no loop, which is what we're trying to

[Med] We don't have a solid motivation to use MUST NOT for such positive case. A lower hop-limit may be an indication that some changes were made to the topology (e.g., adding a proxy), one may argue that it better to let pass the request rather than serving it from the cache to ensure that a positive reply will be still receive. Retrieved response will be cached and then used to service subsequent requests (exact match for positive answers or lower/exact match for hop limit reached response). 

BTW, if there is going to be caching, then every proxy in the chain is likely to cache the (good) response and so the request will get no further than the first proxy.    

> violation if I want to configure my proxy not to include any

[Med] It is not a protocol violation if the information is not included - hence the SHOULD. However it makes diagnosing the issue more difficult.

> any requirements on the formatting.

[Med] Making requirement on the diag is important here because this is used to identify the loop. Note that HTTP also makes some reco about the format of diagnostic information, see https://tools.ietf.org/html/rfc7239 

 Diagnostic information without any
> space characters is probably very hard to read.

[Med] Hmm. This is about a name, IP addresses. These must not include space characters. 

> become so large that Blockwise Transfers [2] are needed.

[Med] We do have doubts about the use of 7959 in this context. It is not obvious from 7959 to see how diagnostic messages can be split over multiple messages without expecting any action from the client + how the intermediate proxy which observes the size is large will handle the transmission of the various fragments.

4.xx is a failure and so while this could be returned with an additional BLOCK2 to the next sender in the chain, we don’t think this will work as the original client is expecting a 2.xx to inspect for a BLOCK2 option to see if the request for the next block of data is needed. Then, how does an interim proxy know that it is to be sending the additional data rather than forwarding the request on to the next proxy.

We suggest that we only prepend if there is sufficient space. We can add NEW text to record this.

---

From: <[email-masked]>
Date: Wed, 26 Jun 2019 06:58:48 +0000

Hi Klaus, Carsten, all, 

Is there any particular text change that you like to see added to the draft to capture (1)?

Cheers,
Med

> > (1) With a way to perform proxy loop mitigation now available, what is
> our recommendation for usage?  Is this something that is (a) specific to
> DOTS, something that (b) it would now be reasonable to expect a proxy to
> add, or (c) something that every CoAP implementation should do?  (At the
> interim, we were leaning towards (b).)
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jun 2019 12:21:38 +0200

> [Med] Making requirement on the diag is important here because this is used to identify the loop. Note that HTTP also makes some reco about the format of diagnostic information, see https://tools.i…

HTTP does not have the concept of diagnostic payload.
The RFC is about an HTTP header field, which of course requires specific syntax; the “Forwarded” header field is equivalent to a CoAP repeatable option.

But none of that really answers Klaus question, if I understand that correctly.

>> space characters is probably very hard to read.

Maybe we should simply use LF (new line) as the separator, so space characters can be included in an entry if needed.  (There still should be some encouragement of restraint in formulating these entries.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jun 2019 12:34:27 +0200

> Is there any particular text change that you like to see added to the draft to capture (1)?

If we develop WG consensus on the intended usage, there probably should be something like

1.1  Intended Usage

   The Hop-Limit option has originally been designed for a specific use case
   [I-D.ietf-dots-signal-channel].  However, its intended usage is general:
   CoAP proxies that do not have specific knowledge that proxy forwarding loops
   are avoided in some other way, are expected to implement this option 
   and have it enabled by default.  
   Note that this means that a server that receives requests both via proxies
   and directly from clients may see otherwise identical requests with and
   without the Hop-Limit option included; servers with internal caching 
   will therefore also want to implement this option (at least as far as 
   needed for ignoring it).

Or so.

BTW, the title should say “Hop-Limit Option” if that is the name we give it.
In the text, “Hop-Limit” should always be used if the option is meant, while “hop limit” should be used to discuss the concept of a hop limit (e.g., what happens when that is reached), and “Hop Limit Reached” should always be used in conjunction with TBA1.

Grüße, Carsten

---

From: <[email-masked]>
Date: Wed, 26 Jun 2019 11:16:39 +0000

Hi Cartsen, 

There are two parts in the comment from Klaus: 
(1) "it seems weird to make any requirements on the formatting" 
(2) "Diagnostic information without any space characters is probably very hard to read"

Using another separator is not adequate given his (1). 

As for (2) it seems that Klaus is mixing the information that is injected by a proxy with the overall diagnostic information. The text he quoted is about a name or an IP address. Such info must not include a space character.  

The diagnostic information will include space characters when more than one proxy is on the path. So, (2) is not accurate. 

Making formatting requirements is important if we would like to ease diag operations.  

Did I missed something? 

Cheers,
Med

> De : Carsten Bormann [mailto:[email-masked]]
> Envoyé : mercredi 26 juin 2019 12:22
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Klaus Hartke; core; [email-masked]
> > [Med] Making requirement on the diag is important here because this is
> used to identify the loop. Note that HTTP also makes some reco about the
> format of diagnostic information, see https://tools.ietf.org/html/rfc7239
> 
> The RFC is about an HTTP header field, which of course requires specific
> syntax; the “Forwarded” header field is equivalent to a CoAP repeatable
> option.
> 
> Maybe we should simply use LF (new line) as the separator, so space
> characters can be included in an entry if needed.  (There still should be
> some encouragement of restraint in formulating these entries.)
> 
> Grüße, Carsten

---

From: <[email-masked]>
Date: Wed, 26 Jun 2019 11:23:06 +0000

Re-, 

> Hop-Limit option/CDN-Loop header field is present.

We will add this NEW text to address it: 

=======
4.  HTTP Mappings

   This section focuses on the HTTP mappings specific to the CoAP
   extension specified in this document.  As a reminder, the basic
   normative requirements on HTTP-to-CoAP mappings are defined in
   Section 10.2 of [RFC7252].  The generic guidelines for HTTP/CoAP
   mappings are elaborated in [RFC8075].

   By default, the HTTP-to-CoAP Proxy inserts a Hop-Limit option
   following the guidelines in Section 3.  Optionally, the HTTP-to-CoAP
   Proxy may be instructed by policy to insert a Hop-Limit option only
   if a 'Via' header is present in the HTTP request.

   The HTTP-to-CoAP Proxy uses 508 (Loop Detected) as the HTTP response
   status code to map TBA1 (Hop Limit Reached).  Furthermore, it maps
   the diagnostic payload of TBA1 (Hop Limit Reached) as per Section 6.6
   of [RFC8075].
=======

Cheers,
Med

---

From: <[email-masked]>
Date: Wed, 26 Jun 2019 11:53:25 +0000

Re-,

Thanks. 

FWIW, this text and other changes to address the WGLCs were included in our working copy:

* https://github.com/boucadair/draft-hop-limit/blob/master/draft-ietf-core-hop-limit-04.txt 
* diff: https://github.com/boucadair/draft-hop-limit/blob/master/wdiff%20draft-ietf-core-hop-limit-03.txt%20draft-ietf-core-hop-limit-04.pdf 

Cheers,
Med

> Envoyé : mercredi 26 juin 2019 12:34
> Cc : Klaus Hartke; core
> In the text, “Hop-Limit” should always be used if the option is meant,
> while “hop limit” should be used to discuss the concept of a hop limit
> (e.g., what happens when that is reached), and “Hop Limit Reached” should
> always be used in conjunction with TBA1.
> 
> Grüße, Carsten
> 
> 
> >
> > Cheers,
> > Med
> >

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 27 Jun 2019 14:06:01 +0200

Hi Mohamed,

thank you for your response. I'm skipping items that I consider resolved.

> [Med] No, it is not a protocol violation (that is the reason for using "SHOULD" and not "MUST").

We briefly discussed this in the interim yesterday and came to the
conclusion that having a normative requirement here isn't needed. It
seems more like a suggestion for a good quality of implementation. I
propose to remove any use of KEYWORDs here.

> [Med] It is not a protocol violation if the information is not included - hence the SHOULD. However it makes diagnosing the issue more difficult.

Same as above.

> [Med] Making requirement on the diag is important here because this is used to identify the loop. Note that HTTP also makes some reco about the format of diagnostic information, see https://tools.i…

I think you need to make a decision here what you want to achieve: Is
it purely about generating useful diagnostics for humans to interpret,
or is it about generating data that a machine can understand?

In the first case, you could suggest that implementations end the text
they're prepending in CR LF (in accordance with RFC 5198). But I think
it would be too restrictive to require implementations to format their
information in a certain way.

In the second case, we could simply define a new media type and use
CDDL and/or ABNF to describe the format.

> [Med] Hmm. This is about a name, IP addresses. These must not include space characters.

Maybe a few examples in the draft would be helpful.

> 4.xx is a failure and so while this could be returned with an additional BLOCK2 to the next sender in the chain, we don’t think this will work as the original client is expecting a 2.xx to inspect…

This is not different from any other proxy-generated error response...

There was some agreement in the interim yesterday though that the use
of blockwise transfers might not be very desirable here.

> We suggest that we only prepend if there is sufficient space. We can add NEW text to record this.

That's one option, but it might be difficult to determine what is
"sufficient space" if the message goes through multiple networks.

Another option is to record only the information of the hop where the
Hop-Limit value reaches 0. Then the payload size would be constant and
not grow with the number of hops in between. If someone debugging the
system needs the information of the hops in between, then they can
send requests with decreasing initial Hop-Limit values.

> Intended Usage

There was agreement in the interim yesterday that it's probably a good
idea to recommend that all CoAP proxies implement this and have it
turned on by default. If in certain deployment it doesn't make sense,
it can be turned off. Something like the text proposed by Carsten in
https://mailarchive.ietf.org/arch/msg/core/dUNMiz-nLBCa4-tblZW5jLaZ5Jg
would be good.

> HTTP Mapping

Mapping the TBA1 (Hop Limit Reached) response code to the 508 (Loop
Detected) status code is probably fine. Mapping between the Hop-Limit
option and Via or CDN-Loop header field is more difficult. I'm not
what what can actually be recommended here.

There's also the problem when a CoAP-to-HTTP and a HTTP-to-CoAP proxy
are sending a message in a loop (possibly with more CoAP and/or HTTP
proxies in between). It would be nice if this could be detected.
Otherwise, maybe some text should be added that this scenario cannot
be detected with the Hop-Limit option.

Klaus

---

From: <[email-masked]>
Date: Thu, 27 Jun 2019 13:29:22 +0000

Hi Klaus, 

Thank you for the follow-up. 

Please see inline.

Cheers,
Med

> De : Klaus Hartke [mailto:[email-masked]]
> Envoyé : jeudi 27 juin 2019 14:06
> Cc : Carsten Bormann; core; [email-masked]

[Med] Will go with the outcome of the interim. 

> > [Med] It is not a protocol violation if the information is not included
> - hence the SHOULD. However it makes diagnosing the issue more difficult.
> 
> Same as above.

[Med] OK.

> Maybe a few examples in the draft would be helpful.

[Med] Will add some. 

> > [Med] We do have doubts about the use of 7959 in this context. It is not
> obvious from 7959 to see how diagnostic messages can be split over
> multiple messages without expecting any action from the client + how the
> intermediate proxy which observes the size is large will handle the
> transmission of the various fragments.
> >
> > 4.xx is a failure and so while this could be returned with an additional
> BLOCK2 to the next sender in the chain, we don’t think this will work as
> the original client is expecting a 2.xx to inspect for a BLOCK2 option to
> see if the request for the next block of data is needed. Then, how does an
> interim proxy know that it is to be sending the additional data rather
> than forwarding the request on to the next proxy.
> 

[Med] I agree with the conclusion to not use the blockwise.

> "sufficient space" if the message goes through multiple networks.

[Med] "sufficient space" is based on the Path MTU. If it can't be determined, 7252 will be followed for determining minimum values. 

> send requests with decreasing initial Hop-Limit values.

[Med] That option will be naturally met if we don't prepend once there is no sufficient space. The value in having the full path when possible is to ease troubleshooting when advanced traffic forwarding are implemented (e.g., load balancing, multipath, etc.) without requiring to further send another trace/probe request. 

> https://mailarchive.ietf.org/arch/msg/core/dUNMiz-nLBCa4-tblZW5jLaZ5Jg

[Med] OK, thanks. We did already include that text in our working copy.

> what what can actually be recommended here.

[Med] The initial proposal is to insert Hop-Limit y default by a http-to-CoAP proxy. Optionally, the proxy can be instructed to insert it only when Via is present. We can update that text to mention "Via or CDN-Loop".

What about the following for CoAP-to-HTTP?
* Map by default Hop-Limit to Via
* Map to CDN-Loop if the proxy is explicitly configured to do so.  

> be detected with the Hop-Limit option.

[Med]  This is similar to the case where a CoAP request crosses multiple administrative domains. What about adding the following:

   When both HTTP-to-CoAP and CoAP-to-HTTP proxies are involved, the
   loop detection may get broken if the proxy-forwarded traffic
   repeatedly crosses the HTTP-to-CoAP and CoAP-to-HTTP proxies.
   Nevertheless, if the loop is within the CoAP or HTTP legs, the loop
   detection is still functional.