Subject: [core] Responses to NON with 4.02

From: Christian Amsüss <[email-masked]>
Date: Tue, 16 Feb 2021 21:29:50 +0100

Hi,

reviewing new-block told me something new about RFC7252, that is that a
response to a NON request containing an unknown critical option MUST be
either RST or complete silence (whereas in the CON case, 4.02 is the
logical response).

Why is that? A NON 4.02 response would be just the same size, give
better information, and (to me, most importantly) would not require the
additional case distinction between "it's a 4.02 because some option
value doesn't make sense" and "it's a 4.02 because I don't know the
particular option" at a very different place than were the options are
understood.

(Or worse yet: A NON may arrive at a proxy that forwards it over TCP or
as a CON, and by the time the proxy gets the 4.02, it doesn't know
either).

And will anything go Really Bad if I ignore that MUST? (I currently do
-- up to now for ignorance, going forward because my libraries all work
under the fiction that the library is an intermediary, and thus may do
all things an intermediary may do).

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Achim Kraus <[email-masked]>
Date: Wed, 17 Feb 2021 09:21:12 +0100

Hello Christian,

I think, this discussion from April 2020 is at least related to your
question.

https://mailarchive.ietf.org/arch/msg/core/wd4LleVnnvt2WOXj28ouNZcCTXU/

best regards
Achim Kraus

Am 16.02.21 um 21:29 schrieb Christian Amsüss:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 17 Feb 2021 09:27:28 +0100

Hi Achim,

> https://mailarchive.ietf.org/arch/msg/core/wd4LleVnnvt2WOXj28ouNZcCTXU/

thanks, that's indeed essentially the same question, I just failed to
find it.

I concur with Klaus that it's weird and belongs to the request/response
layer.

Just to ensure I didn't miss anything too relevant in my (so far, to be
continued) "I just pretent to be a proxy" excuse, what were the
complaints you got about the behavior about? For whatever gets upset by
your original implementation would probably also get upset by the
presence of proxies.

BR
c

---

From: Achim Kraus <[email-masked]>
Date: Wed, 17 Feb 2021 09:42:39 +0100

Hi Christian,

 > what were the complaints you got about the behavior about?

(Hope, I understand that ...)

3 years ago, a colleague was working on the the option validation and
found, that this seems to be wired in the specification.

Last year the Eclipse/Californium project got a similar request about that,

https://github.com/eclipse/californium/issues/1288

and so I decided to ask the list about the intention behind that.

AFAIK, there is no real issue with that. Basically the main failure is
sending the "bad option", not the way, the other peer responds. So the
behavior seems to be more important for developing and debugging then
for real production. And during developing it should be not too hard, to
switch to CON to see, which error response your get back.

best regards
Achim Kraus

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 17 Feb 2021 09:55:22 +0100

> (Hope, I understand that ...)

Precisely as I meant it :-)

> found, that this seems to be wired in the specification.

OK thanks, so both look more like "it confused people" than "it confused
software", so no urgent action needed.

IMO this is something to put in corrections and clarifications; issue
now open at <https://github.com/core-wg/corrclar/issues/14>.

Thank you
Christian

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn