Subject: Re: [core] RST and NON (was Re: explicit observe de-registration)

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 2 Mar 2012 12:20:41 +0000

Dear list

I still see conflict with RST and NON, especially for observe:
Usually, the sender does not store any transaction information for a NON message (and cannot unless he also introduces timers for NON, which kind of breaks the concept).
But how should the sender identify the context when a RST arrives in reply to a NON? The RST has  must be empty and there is no matching message ID...
Observe makes use of RST to cancel a relationship by the client, but which one should be removed at server side when it is an answer to a NON notification?
Maybe RSTs should be able to carry the context, so the peer knows what to reset?

Best regards
Matthias

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Salvatore Loreto
Gesendet: Mittwoch, 15. Februar 2012 09:35
An: [email-masked]
Betreff: [core] RST and NON (was Re: explicit observe de-registration)

Hi there,

from on the Thomas mail (see below) and the thread discussion related on how to cancel an observation
it seems that the core-coap 08 draft needs some text to clarify how the RST message works and when it is possible to use it.

sections seems to imply that RST MUST be used only with confirmable messages

4.4.4.  Reset (RST)

   A Reset message indicates that a specific confirmable message was

   received, but some context is missing to properly process it.  This

   condition is usually caused when the receiving node has rebooted and

   has forgotten some state that would be required to interpret the

   message.

   A reset message MUST echo the Message ID of the confirmable message,

   and MUST be empty.

however, section 4.2 states that it MAY be used also with an Unreliable Message

4.2.  Unreliable Messages

   As a more lightweight alternative, a message can be transmitted less

   reliably by marking the message as "non-confirmable".  A non-

   confirmable message MUST NOT be acknowledged by the recipient.  If a

   recipient lacks context to process the message properly, it MAY

   reject the message with a reset message or otherwise MUST silently

   ignore it.

--

Salvatore Loreto

www.sloreto.com<http://www.sloreto.com>

On 2/13/12 12:35 PM, Thomas Fossati wrote:

Wouldn't it be cleaner to have an explicit Observe de-registration request from the observer to the subject ?

It'd work with both CON and NON observations (instead of being CON-only [*]) and would be more efficient with sleepy observers, avoiding all the useless retransmission implied by an unreachable node that has entered the sleep state.

Thomas.

[*] apropos, section 4.3 of coap-08 seems to imply that RST can be sent in reply to a NON message, but then 4.4.4 associates RST to CON only (consistently with the usage in current Observe I-D.).  To add some more entropy, the changelog says that 05->06 transition included an "Allowed RST message in reply to a NON message with unexpected token", but I can't see it anywhere in -08.

This all leaves some degree of ambiguity about whether RST is a valid response to a NON message or not.

_______________________________________________

core mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/core

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 2 Mar 2012 12:27:11 +0000

Or it should be made clear somewhere that a RST resets all relationships for a client (identified by address and port only).

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Kovatsch Matthias
Gesendet: Freitag, 2. März 2012 13:21
An: [email-masked]
Betreff: Re: [core] RST and NON (was Re: explicit observe de-registration)

Dear list

Best regards
Matthias

Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> Im Auftrag von Salvatore Loreto
Gesendet: Mittwoch, 15. Februar 2012 09:35
An: [email-masked]<mailto:[email-masked]>
Betreff: [core] RST and NON (was Re: explicit observe de-registration)

Hi there,

4.4.4.  Reset (RST)

   message.

   and MUST be empty.

4.2.  Unreliable Messages

   ignore it.

--

Salvatore Loreto

Thomas.

core mailing list

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Mar 2012 14:27:14 +0100

On Mar 2, 2012, at 13:20, Kovatsch Matthias wrote:

> The RST [...]  must be empty

Yes.

> and there is no matching message ID…

Here is the point of confusion:
Yes, there is.  2.1:

...
   Non-confirmable message (NON).  These are not acknowledged, but still
   have a Message ID for duplicate detection; see Figure 3.

See also 4.3.

But I understand your question:
I don't think the current design is exactly beautiful.

A normal NON sender implementation will not register that message ID, because there is nobody that would be interested in any feedback.
Here, however, the server being observed *is* interested, so within the implementation it should pass a flag "please register this MID even though it is a NON".
It would then be able to match back the RST to the NON.

Clearly, this is bending the semantics of NON a bit -- you can RST it, but can't ACK it.
I think the right way to handle this conflict is to make reacting to RSTs that are being sent back for NONs, an implementation decision.
If a server doesn't have the means to keep the MID, well, then it will keep sending NONs despite the incoming RSTs until it finally decides to probe the observer with CON.

So this would be one combination of choices:
-- receivers are not obliged to send RST to NON
-- senders are not obliged to implement NON-RST-matching
-- senders *ARE* obliged to occasionally probe using CON.

Another combination:
-- receivers *ARE* obliged to send RST on NON they don't know what to do with
-- senders *ARE* obliged to handle these RST
-- senders are not obliged to probe.

But the latter combination would still not cover the case where the receiver vanishes in a black hole.  (If it simply goes away, there will be unreachables after a while -- these should work as well as a RST.)

Again, I'm not entirely sure we have hit the right combination, but I think it is the best solution we have right now.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 2 Mar 2012 13:48:21 +0000

So making RST a full peer reset is not an option? It would carry all the information required for that (address+port).

It would make sense to me because a client for instance could only "forget" an observing relationship because of a crash/reset (not counting implementation bugs). But after a crash, all relationships would be gone anyway. For selective cancellation, observing for instance still provides the GETs without the observe option.
The full peer reset would also fit a DoS attack scenario where faked subscriptions could cause the bombardment of one client. Just thinking...

> -----Ursprüngliche Nachricht-----
> Von: Carsten Bormann [mailto:[email-masked]]
> Gesendet: Freitag, 2. März 2012 14:27
> An: Kovatsch Matthias
> Cc: [email-masked]
> > and there is no matching message ID.
> 
> A normal NON sender implementation will not register that message ID, because
> there is nobody that would be interested in any feedback.
> Here, however, the server being observed *is* interested, so within the
> implementation it should pass a flag "please register this MID even though it is a
> NON".
> I think the right way to handle this conflict is to make reacting to RSTs that are
> being sent back for NONs, an implementation decision.
> If a server doesn't have the means to keep the MID, well, then it will keep
> sending NONs despite the incoming RSTs until it finally decides to probe the
> observer with CON.
> 
> But the latter combination would still not cover the case where the receiver
> vanishes in a black hole.  (If it simply goes away, there will be unreachables after
> a while -- these should work as well as a RST.)
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Mar 2012 15:18:26 +0100

> So making RST a full peer reset is not an option? It would carry all the information required for that (address+port).

Yes, I seem to remember we had that discussion before....  
I'm still trying to remember the context.  Klaus, do you remember?

But I'd keep the MID matching, regardless of whether the RST only clears the observation relationship that used this particular MID or all observation relationships on this transport address pair.  Without MID matching, it becomes too easy to spray the world with RSTs as a DoS (yes, 16 bits is a weak mitigation, but it is something, and it is additionally aided by the window during which the NON is alive).

> It would make sense to me because a client for instance could only "forget" an observing relationship because of a crash/reset (not counting implementation bugs). But after a crash, all relationships would be gone anyway.

Right.

> For selective cancellation, observing for instance still provides the GETs without the observe option.

That would also fit the likely timing relationships better -- it is less likely that a client suddenly finds out on a NON notification that it really no longer wants the data.
More likely, there is an independent trigger that causes the client to stop the relationship, and no suitably recent NON may be lying around then to send a RST on, so it is likely to implement the GET code path in any case.  But this is now becoming a bit of speculation...  Maybe sending the 4-byte RST is exactly what the doctor ordered...

> The full peer reset would also fit a DoS attack scenario where faked subscriptions could cause the bombardment of one client. Just thinking...

Yes, but see above.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 2 Mar 2012 14:40:01 +0000

> But I'd keep the MID matching, regardless of whether the RST only clears the
> observation relationship that used this particular MID or all observation
> relationships on this transport address pair.  Without MID matching, it becomes
> too easy to spray the world with RSTs as a DoS (yes, 16 bits is a weak mitigation,
> but it is something, and it is additionally aided by the window during which the
> NON is alive).
> 
> > The full peer reset would also fit a DoS attack scenario where faked
> subscriptions could cause the bombardment of one client. Just thinking...
> 
> Yes, but see above.

True.

Okay, so I will probably add the last used MIDs to the observer state at the server.

Thanks for the clarification!
Matthias

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 2 Mar 2012 16:47:29 +0100

> I'm still trying to remember the context.  Klaus, do you remember?

We had the discussion if a confirmable notification that ultimately
times out should cause the server to remove the client from all lists
of observers.

   When the last attempt to retransmit a
   confirmable message with a notification for a resource times out, the
   server SHOULD remove the client from the list of observers and MAY
   additionally remove the client from the lists of observers of all
   resources in its namespace.
   (http://tools.ietf.org/html/draft-ietf-core-observe-04#section-4.5)

I'm not sure if this should also be done if the client sends a RST.
RST means that the recipient of a CON/NON message is missing some
context to process the message, whatever this context might be, not
necessarily that it lost everything.

Klaus