Internet DRAFT - draft-amsuess-core-request-tag
draft-amsuess-core-request-tag
CoRE Working Group C. Amsuess
Internet-Draft Energy Harvesting Solutions
Intended status: Standards Track March 27, 2017
Expires: September 28, 2017
Request-Tag option
draft-amsuess-core-request-tag-00
Abstract
This memo describes an optional extension to the Constrained
Application Protocol (CoAP, [RFC7252] and [RFC7959]) that allows
matching of request blocks. This primarily serves to transfer the
security properties that Object Security of CoAP (OSCOAP,
[I-D.ietf-core-object-security]) provides for single requests to
blockwise transfers. The security of blockwise transfer in OSCOAP is
reflected on in a dedicated section.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Amsuess Expires September 28, 2017 [Page 1]
Internet-Draft Request-Tag option March 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Request-Tag option . . . . . . . . . . . . . . . . . . . 3
2.1. For inclusion in OSCOAP . . . . . . . . . . . . . . . . . 4
3. Security properties of blockwise transfer . . . . . . . . . . 5
3.1. Blockwise transfer cases . . . . . . . . . . . . . . . . 6
3.2. Attack scenarios . . . . . . . . . . . . . . . . . . . . 8
3.2.1. "Promote Valjean" (on blockwise case SN) . . . . . . 9
3.2.2. "Free the hitman" (blockwise case SN or SS) . . . . . 10
4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Use of Request-Tag by proxies . . . . . . . . . . . 13
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 13
B.1. OSCOAP inner-blockwise . . . . . . . . . . . . . . . . . 13
B.2. Use by proxies . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The OSCOAP protocol provides a security layer for CoAP that, given a
security context shared with a peer, provides
o encryption of payload and some options,
o integrity protection of the encrypted data and some more message
options,
o protection against replays once a request has reached the server,
and
o protected matching between request and response messages.
It does not (and should not) provide sequential delivery. In
particular, it does not protect against requests being delayed; the
corresponding attack and mitigation is described in
[I-D.mattsson-core-coap-actuators].
The goal of this memo is to provide protection to the bodies of a
blockwise fragmented request/response pair that is equivalent to the
protection that would be provided if the complete request and
Amsuess Expires September 28, 2017 [Page 2]
Internet-Draft Request-Tag option March 2017
response bodies fit into single messae each. (Packing long payloads
into single OSCOAP messages is actually possible using the outer
blockwise mechanism, but does not go well with the constraints of
devices CoAP is designed for). [Author's note: The results of this
might move back into OSCOAP - for now, the matter is explored here.]
The proposed method of matching blocks to each other is the
introduction of a Request-Tag option, which is similar to the ETag
sent along with responses, but ephemeral and set by the client. It
is phrased in a way that it can not only be used in OSCOAP, but also
by other security mechanisms (eg. CoAP over DTLS), or for other
purposes (see Appendix A).
In order to minimize the impact on message sizes, the Request-Tag
option is designed to be only used when required[, and its
interaction with OSCOAP should mandate actively setting it only in
rare cases. If this is still insufficient, compressing it into the
AAD can still be considered].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terms "payload" and "body" are used as in [RFC7959]. The
complete interchange of a request and a response body is called a
REST "operation", while a request and response message (as matched by
their tokens) is called an "exchange".
2. The Request-Tag option
A new option is defined for all request methods:
+-----+---+---+---+---+-----------------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+-----------------------+--------+--------+---------+
| TBD | x | x | - | | Request-Tag | opaque | 0-8 | (none) |
+-----+---+---+---+---+-----------------------+--------+--------+---------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Figure 1: Option summary
It is critical (because a client that wants to secure its request
body can't have a server ignore it), unsafe (because it needs to
understood by any proxy that does blockwise (dis)assembly), and not
repeatable. ([Does "unsafe" make nocachekey irrelevant? I think
so.])
Amsuess Expires September 28, 2017 [Page 3]
Internet-Draft Request-Tag option March 2017
A client MAY set the Request-Tag option to indicate that the
receiving server MUST NOT act on any block in the same blockwise
operation that has a different Request-Tag set. A server MUST NOT
use blocks with and blocks without Request-Tag option either.
[Note on future development: If it turns out we need to compress the
option into the AAD, this might hook in here and specify that when
OSCOAP and blockwise is in use, the client MUST set a Request-Tag if
and only if it sets a Block1 option in descriptive usage, and is
value MUST be the partial IV of that message. That value MUST then
be included somewhere in the AAD of every block message _after_ the
first, where this compression proposal so far fails because the
verifying server would have to know at AAD-building time whether or
not this is an inner blockwise request.]
If the Request-Tag option is set, the client MAY perform simultaneous
operations that utilize Block1 fragmentation from the same endpoint
towards the same resource, lifting the limitation of [RFC7959]
section 2.5. The server is still under no obligation to keep state
of more than one transaction. When an operation is in progress and a
second one can not be served at the same time, the server MUST either
respond to the second request with a 5.03 response code (in which it
SHOULD indicate the time it is willing to wait for additional blocks
in the first open operation in the Max-Age option), or cancel the
first operation by responding 4.08 in subsequent exchanges in the
first operations. Clients that see the latter behavior SHOULD [or
MUST?] fall back to serializing requests as it would without the
Request-Tag option.
[Author's note: The above paragraph sounds problematic to me. For
further exploration of those error cases, I'd need to know how
simultaneous operations (even on different resources) from different
endpoints are handled in constrained clients; I only did stateless
operations in constrained devices so far.]
The option is not used in responses.
If a request that uses Request-Tag is rejected with 4.02 Bad Option,
the client MAY retry the operation without it, but it then needs to
serialize all operations that affect the same resource. Security
requirements can forbid dropping the Request-Tag option.
2.1. For inclusion in OSCOAP
[Author's note: If this stays a document of its own, OSCOAP should
make a normative reference to it and state something like:
Amsuess Expires September 28, 2017 [Page 4]
Internet-Draft Request-Tag option March 2017
Whenever the Block1 option is used as inner option, the Request-
Tag option must be considered. A Request-Tag value (where the
absence of a Request-Tag option is counted as a value too, and
distinct from the empty option) can only be reused when all
request messages sent in a different exchange with the same option
value have either been answered (and successfully unprotected), or
their sender sequence numbers differ from the next request by at
least the window size (in which case they can not be accepted by
the server after the new request has started).
If the client follows the suggestion of only storing its own
sequence numbers to persistent memory every K requests, it must
increment the stored sequence number counter before using the last
window-size sequence numbers available, because the remaining
sequence numbes might only be used with certain constraints (it
might be necessary to set a Request-Tag on them).
With this text, clients could even work around ever needing to send
the option by bumping their sequence number - looks like bad behavior
in the first place, but then again, it is just a variant of the
"forbid out-of-order sequence numbers in blockwise" alternative
option.
AFAICT this would be the first actual use of the window size; so far
client and server can well interact with different replay window
sizes. Probably it's OK to be the first user of the parameter.
For the options list:
The Request-Discriminator option is added to the "E=*" category in
the options list, and is listed together with Block1/2 in all other
places they are mentioned.
For somewhere else (?):
A server responding an inner Block2 option SHOULD use an ETag on it,
even if the result is not cachable (eg. the response to a POST
request), and take reasonable measures against identical ETags on
distinct states, otherwise OSCOAP does not provide integrity
protection of the response body.
]
3. Security properties of blockwise transfer
Blockwise transfer, specified in [RFC7959], fragments REST operations
into exchanges of individual blocks. It provides, at the discretion
of the server, direct access to parts of a resource representation
Amsuess Expires September 28, 2017 [Page 5]
Internet-Draft Request-Tag option March 2017
(where the client can fetch or send any block in any sequence, also
called "random access") or sequential access (where the operation is
started by exchanging the first block, and terminates in the exchange
of the last block).
The individual blocks are correlated only by the client _endpoint_
(or security context if applicable), the requested _URI_, and _time_
(and thereby server state, where the operation is available at most
until another request with the same endpoint/URI combination
arrives).
The specification does include security considerations, which do
advise against allowing random write access, but does not contain a
mechanism that allows protecting the integrity of the operation's
body. Consequently, the attacks described below are possible even
when blockwise transfer is used over DTLS to the author's knowledge.
3.1. Blockwise transfer cases
There are several shapes a blockwise exchange can take, named here
for further reference. Requests or responses bodies are called
"small" or "large" here if they do or do not, respectively, fit in a
single message. Empty bodies are small. Naming consists of case
discrimination letters for No blockwise, Sequential transfer and
Random access in the Block1 and Block2 phases, respectively.
[Author's note: I'd appreciate real examples to replace the more
contrived ones; the worst are marked with (?).]
o _NN_: Request and response bodies are both small. No
fragmentation happens.
Examples: GETs to sensors, PUTs to actors.
Integrity protection: Request/response matching is sufficient.
o _NS_: A small request causes a large response, which gets
fragmented and sequentially fetched by the client.
Examples: GETting an unfiltered link-format list, PUTting a
compressed image to a picture frame that decides to return its
(decompressed) state in full in the response(?).
Integrity protection: The full request is copied in each
subsequent request.
Changes in the response need to be covered by the server setting a
unique ETag.
Amsuess Expires September 28, 2017 [Page 6]
Internet-Draft Request-Tag option March 2017
Client and server could still disagree over whether the requests
constitute a single or distinct REST operations; that's a general
issue that should be pointed out. Note, however, that the _SS_
case _does_ provide that distinction! ["making non-blockwise as
safe as blockwise" is not part of the mission statement (only the
other way round), so probably we should accept this here and not
try to provide that assurance - it would make every request a
Request-Tag candidate, and rule out anything but NSTART=1 because
the client couldn't know whether Block2 will be used.]
o _NR_: A small request is used to access a large one at random
offsets.
Examples: Inspecting a device's exposed memory.
Integrity protection: Likewith _NS_, just that the distinction
between single and distinct REST operations is presumably [check!]
not meaningful anyway.
o _SN_: A large request is sent in sequential blocks with a small
(typically empty) response.
The server can, after any block, indicate that it has processed
the blocks so far, and send a status for the processed ones.
Examples: FETCHing a complex query, POSTing one's resource list to
a resource directory.
Integrity protection: The same Request-Tag gets set to all request
blocks. The server treats blocks with a different tag (eg.
replays from an earlier transmission) as different operations and
possibly rejects them as incomplete entities.
o _RN_: A large request is sent in a random-access pattern,
resulting in a small response(s) (typically, one response each, as
the server would in that scenario send successful responses after
each block or small groups of blocks.
Examples: Storing data in a memory region of a device. (?)
Integrity protection: The client can set a Request-Tag if it wants
to group operations, but there is presumably [check!] no
correlation to protect anyway.
o _SR_, _RR_: Large requests (sequentially or randomly requested)
that have their large responses fetched in random access patterns
- these cases are explicitly forbidden in blockwise transfer
([RFC7959] section 2.7).
Amsuess Expires September 28, 2017 [Page 7]
Internet-Draft Request-Tag option March 2017
o _RS_: [That's a tough one. A) I can't come up with examples, and
B) the same section 2.7 says that Block2 processing starts when
the _last_ block is done, implying that the request is sequential
but not outright prescribing it. Furthermore, can there be
inbetween successful replies? ]
o _SS_: A large request is sent sequentially, and the large response
is fetched in sequential blocks after the request has been
transmitted in full.
Integrity protection: The client sets a Request-Tag as in the _SN_
case. The last exchange (itself protected by OSCOAP's request/
response matching) carries the Request-Tag option, and as with
_NS_, the server sets an ETag.
This is a case for which the Request-Tag use might need extending
to the Block2 phase; while the protection is sufficient by passing
the link on from Request-Tag to ETag, the server's state might be
overridden by a simultaneous request (which the Request-Tag option
promises to deal with), and the client may fail to retrieve the
data because another request clears the state. This is
problematic more for the proxy use case than for protected
blockwise transfers. It is not fatal for the proxy case, though:
It would need to serialize only the last exchange of the Block1
phase and the complete Block2 phase, but in that it does not
depend on the client's data any more, can finish the Block2 phase
quickly and spool the data for the client to fetch before
finishing the next operation.
[Note that the _NS_ picture frame example is by far the worst and
farest-fetched. I'd like to have an example of a non-safe request
resulting in fragmented responses, but that behavior is usually
discouraged (PUT responses typically being empty, POST responses
bearing a Location), but not outright forbidden, and catered for in
blockwise where it comes to combined use of Block1 and Block2.]
3.2. Attack scenarios
This section outlines some attacks that should be mitigated by the
Request-Tag option. They are written with a malicious proxy between
client and server in mind; whether that is a forward, reverse,
transparent proxy, or any other entity on the data path that can
intercept and inject packages into the communication is irrelevant to
the attacks.
The illustrations draw terminology (especially the "@" and "X"
symbols) from [I-D.mattsson-core-coap-actuators].
Amsuess Expires September 28, 2017 [Page 8]
Internet-Draft Request-Tag option March 2017
The scenarios typically require the attacker to have a good idea of
the content of the packages that are transferred. Note that the
attacker can see the codes of the messages.
3.2.1. "Promote Valjean" (on blockwise case SN)
In this scenario, blocks from two operations on a POST-accepting
resource are combined to make the server execute an action that was
not intended by the authorized client. This works only if the client
attempts a second operation after first operation failed (due what
the attacker made appear like a network outage) within the replay
window. The client does not receive a confirmation on the second
operation either, but by the time, the server has already executed
the unauthorized action.
Client Foe Server
| | |
+-------------> POST "incarcerate" (Block1: 0, more to come)
| | |
<-------------+ 2.31 Continue (Block1: 0 received, send more)
| | |
+----->@ | POST "valjean" (Block1: 1, last block)
| | |
+----->X | All retransmissions dropped
| | |
(Client: Odd, but let's go on and promote Javert)
| | |
+-------------> POST "promote" (Block1: 0, more to come)
| | |
| X<-----+ 2.31 Continue (Block1: 0 received, send more)
| | |
| @------> POST "valjean" (Block1: 1, last block)
| | |
| X<-----+ 2.04 Valjean Promoted
Figure 2: Attack example
With Request-Tag in place, the client would have assigned a different
Request-Tag to the "promote" line, and the server would have either
reacted to the "valjean" POST by incarcerating valjean (if it could
keep both operation states at the same time), or responded 5.03 to
the "promote" request until a timeout, or responded 4.08 to the
injected "valjean" request.
Amsuess Expires September 28, 2017 [Page 9]
Internet-Draft Request-Tag option March 2017
The client would only have been free to use the same Request-Tag on
the "promote" POST as on the "incarcerate" POST if, in the meantime,
it had exchanged enough messages that the latest message of the first
use ("valjean") is dropped from the server's window, and thus the
sever would not accept its replay.
3.2.2. "Free the hitman" (blockwise case SN or SS)
In this example, mismatched Block1 packages against a resource that
passes judgement are mixed up to create a response matched to the
wrong operation.
Again, a first operation is aborted by the proxy ("Homeless stole
apples. What shall we do with him?" - "Set him free."), and a part
of that operation is later used in a different operation to prime the
server for responding leniently to another operation that would
originally have been "Hitman killed someone. What shall we do with
him?" - "Hang him.".
Client Foe Server
| | |
+----->@ | POST "Homeless stole apples. Wh"
| | | (Block1: 0, more to come)
(Client: We'll try that one later again; for now, we have something more
urgent:)
| | |
+-------------> POST "Hitman killed someone. Wh"
| | | (Block1: 0, more to come)
| | |
| @<-----+ 2.31 Continue (Block1: 0 received, send more)
| | |
| @------> POST "Homeless stole apples. Wh"
| | | (Block1: 0, more to come)
| | |
| X<-----+ 2.31 Continue (Block1: 0 received, send more)
| | |
<------@ | 2.31 Continue (Block1: 0 received, send more)
| | |
+-------------> POST "at shall we do with him?"
| | | (Block1: 1, last block)
| | |
<-------------+ 2.05 "Set him free."
(Block1: 1 received, and this is the result)
Figure 3: Attack example
Amsuess Expires September 28, 2017 [Page 10]
Internet-Draft Request-Tag option March 2017
The example works equivalently with longer responses, placing it in
the _SS_ category instead of the _SN_.
[More examples would help, especially for the other blockwise cases.
Is it relevant to distinguish non-piggybacked responses?]
4. Rationale
This part is informative and serves to illustrate why this option is
necessary, and how it is different from similar concepts.
Why not...
o forbid out-of-order sequence numbers in blockwise?
This could be a viable path. To see whether this works, the
Section 3.1 chapter would hopefully help. (It should not rule out
legitimate cases of random acces, after all).
This would exclude other uses of the option like that in
Appendix A.
o put an option in OSCOAP?
This would work, and might in the end happen with compression of
the Request-Tag option into the AAD.
As before, this would exclude other uses cases.
o open up an endpoint per operation?
This was explored in an earlier draft version as Request-
Discriminator, which would have been a lightweight way to
"multiplex" different endpoints (at least for the purpose of
blockwise making references to them) into one secured connection.
It is still the author's assumption that this would laregly be
equivalent to the Request-Tag both in the OSCOAP application and
in the use case explored in Appendix A, but the Request-Tag path
is being explored currently because it is easier to understand,
explain and reason about, while the Request-Discriminator way
might result in less normative text with more comments, and
possibly have similar effects in implementation codebases.
A Request-Discriminator option could, among other things, be used
by a proxies that act as OSCOAP terminators (eg. network
interfaces in composite devices that use unencrypted CoAP on
internal serial lines) to disambiguate request from different
Amsuess Expires September 28, 2017 [Page 11]
Internet-Draft Request-Tag option March 2017
security contexts towards crypto-unware but blockwise-capable
components.
5. Security Considerations
When used in combination with OSCOAP or other security layers to
prevent block mixing between REST operations, it is crucial to only
reuse request tags as specified, and not to use any affected sequence
numbers (which means the latest sequence number plus the window size)
should information about used request tags get lost.
While the Request-Tag is not echoed back by the server unlike the
Token, the client should still refrain from setting it to internal
values (like memory address of state data) to avoid exposing internal
data to a server that it could use in unrelated attacks.
6. IANA Considerations
[Missing: have a number assigned and the option published]
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<http://www.rfc-editor.org/info/rfc7959>.
7.2. Informative References
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-ietf-core-
object-security-01 (work in progress), December 2016.
Amsuess Expires September 28, 2017 [Page 12]
Internet-Draft Request-Tag option March 2017
[I-D.mattsson-core-coap-actuators]
Mattsson, J., Fornehed, J., Selander, G., and F.
Palombini, "Controlling Actuators with CoAP", draft-
mattsson-core-coap-actuators-02 (work in progress),
November 2016.
Appendix A. Use of Request-Tag by proxies
In pre-OSCOAP practice, proxies rarely face situations where
simultaneous Block1 operations from different affect a single
resource and can not be executed in parallel due to the constraints
of only one Block1 operation being possible per endpoint pair and
resource. (If that happens, the proxy can either serialize the
requests, or 5.03 the second requester until the first request has
completed).
With OSCOAP, all clients access the resource "/" as far as a proxy is
concerned, which would lead to more frequent situations in which it
would need to serialize requests. Clients that employ OSCOAP's
outer-blockwise mechanism find themselves in a similar situation.
Those proxies and clients can utilize the Request-Tag option work off
those requests in parallel by assigning them different Request-Tag
values. To a proxy, this will only mean an increase in state of up
to eight bytes per operation (if it could handle unencrypted
simultaneous requests, it would tell them apart by their URIs; here,
it tells them apart by their request tags). The state a server needs
to keep per operation increases by the same eight bytes compared to
serving the same simultaneous requests directly to different
endopoints.
Appendix B. Examples
B.1. OSCOAP inner-blockwise
All messages exchanged in the following diagrams transferred as
OSCOAP protected messages. The field data shown indicates code,
payload and options of the unprotected (ie. inner) messages.
Payloads are symbolic and do not necessarily line up in any block
size when taken literally. Sequence numbers used are indicated at
the sender side, and the window size used is 32.
Figure 4 shows how under usual circumstances, the Request-Tag option
does not need to be set:
Amsuess Expires September 28, 2017 [Page 13]
Internet-Draft Request-Tag option March 2017
Client Server
| |
[1]-----------> POST "incarcerate" (Block1: 0, more to come)
| |
<----------[11] 2.31 Continue (Block1: 0 received, send more)
| |
[2]-----------> POST "valjean" (Block1: 1, last block)
| |
<----------[12] 2.04 Valjean incarcerated (Block1: 1 received)
| |
[3]-----------> POST "promote" (Block1: 0, more to come)
| |
<----------[13] 2.31 Continue (Block1: 0 received, send more)
| |
[4]-----------> POST "javert" (Block1: 1, last block)
| |
<----------[14] 2.04 Javert promoted (Block1: 1 received)
Figure 4: Back to back block transfer
If there is any doubt about whether all sent sequence numbers of a
Request-Tag value are either acknowledged or off the window, the
client uses a different value as in Figure 5. The client here uses
the shortest possible value, the empty string:
Amsuess Expires September 28, 2017 [Page 14]
Internet-Draft Request-Tag option March 2017
Client Server
| |
[1]-----------> POST "incarcerate" (Block1: 0, more to come)
| |
<----------[11] 2.31 Continue (Block1: 0 received, send more)
| |
[2]---X | POST "valjean" (Block1: 1, last block)
| |
(extended network outage; when it's over, the client attempts a different
operation:)
[3]-----------> POST "promote" (Block1: 0, more to come;
| | Request-Tag: "")
| |
<----------[12] 2.31 Continue (Block1: 0 received, send more)
| |
[4]-----------> POST "javert" (Block1: 1, last block;
| | Request-Tag: "")
| |
<----------[14] 2.04 Javert promoted (Block1: 1 received)
Figure 5: Behavior after extended package loss
B.2. Use by proxies
A proxy can use the Request-Tag option to work off operations from
different clients (indicated by the two origin lines under "Clients")
towards a single resource:
Clients Proxy Server
| | |
+-----> | POST "Homeless stole apples. Wh"
| | | (Block1: 0, more to come)
| | |
| +------> POST "Homeless stole apples. Wh"
| | | (Block1: 0, more to come)
| | |
| <------+ 2.31 Continue (Block1: 0 received, send more)
| | |
<-----+ | 2.31 Continue (Block1: 0 received, send more)
| |
|
+-------> | POST "Hitman killed someone. Wh"
| | | (Block1: 0, more to come)
| | |
| +------> POST "Hitman killed someone. Wh"
| | | (Block1: 0, more to come; Request-Tag: "")
Amsuess Expires September 28, 2017 [Page 15]
Internet-Draft Request-Tag option March 2017
| | |
| <------+ 2.31 Continue (Block1: 0 received, send more)
| | |
<-------+ | 2.31 Continue (Block1: 0 received, send more)
| | |
| | | |
|-----> | POST "at shall we do with him?"
| | | (Block1: 1, last block)
| | |
| +------> POST "at shall we do with him?"
| | | (Block1: 1, last block)
| | |
| <------+ 2.05 "Set him free."
| | | (Block1: 1 received, and this is the result)
| | |
<-----+ | 2.05 "Set him free."
| | | | (Block1: 1 received, and this is the result)
|
|-------> | POST "at shall we do with him?"
| | | (Block1: 1, last block)
| | |
| +------> POST "at shall we do with him?"
| | | (Block1: 1, last block, Request-Tag: "")
| | |
| <------+ 2.05 "Hang him."
| | | (Block1: 1 received, and this is the result)
| | |
<-------+ | 2.05 "Hang him."
| | | (Block1: 1 received, and this is the result)
Figure 6: Proxy example
Author's Address
Christian Amsuess
Energy Harvesting Solutions
Email: c.amsuess@energyharvesting.at
Amsuess Expires September 28, 2017 [Page 16]