Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-02-24
|
14 | (System) | Received changes through RFC Editor sync (created alias RFC 9175, changed title to 'Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing', changed abstract … Received changes through RFC Editor sync (created alias RFC 9175, changed title to 'Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing', changed abstract to 'This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended).', changed pages to 27, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-02-24, changed IESG state to RFC Published, created updates relation between draft-ietf-core-echo-request-tag and RFC 7252) |
2022-02-24
|
14 | (System) | RFC published |
2022-02-04
|
14 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-12-24
|
14 | (System) | RFC Editor state changed to AUTH48 |
2021-10-25
|
14 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-10-18
|
14 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2021-10-18
|
14 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Klaas Wierenga was marked no-response |
2021-10-13
|
14 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-10-13
|
14 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-10-13
|
14 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-10-13
|
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-10-11
|
14 | (System) | RFC Editor state changed to EDIT |
2021-10-11
|
14 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-10-11
|
14 | (System) | Announcement was received by RFC Editor |
2021-10-08
|
14 | (System) | IANA Action state changed to In Progress |
2021-10-08
|
14 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-10-08
|
14 | Cindy Morgan | IESG has approved the document |
2021-10-08
|
14 | Cindy Morgan | Closed "Approve" ballot |
2021-10-08
|
14 | Cindy Morgan | Ballot approval text was generated |
2021-10-08
|
14 | Cindy Morgan | Ballot writeup was changed |
2021-10-08
|
14 | Francesca Palombini | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2021-10-04
|
14 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-14.txt |
2021-10-04
|
14 | (System) | New version approved |
2021-10-04
|
14 | (System) | Request for posting confirmation emailed to previous authors: Christian Amsuess , Goeran Selander , John Mattsson |
2021-10-04
|
14 | Christian Amsüss | Uploaded new revision |
2021-08-30
|
13 | Benjamin Kaduk | [Ballot comment] I really like the changes made in the -13 overall; thank you for adding in all the additional discussion. I only have editorial/nit-level … [Ballot comment] I really like the changes made in the -13 overall; thank you for adding in all the additional discussion. I only have editorial/nit-level comments remaining. Section 2.5.2 The information extracted by the server from the request Echo value has different sources of truth depending on the application. I think that the "sources of truth" phrase might be a source of confusion for some readers. I'd consider something more like: % The request Echo value conveys freshness information to the server, % and the freshness is applied to some data or information related % to the request. which then transitions decently into "Understanding who or what is the authoritative source of that information helps the server implementer decide ..." If all that the server extracts is information which the client is authorized to provide arbitrarily, (which is another way of saying that the server has to trust the client on whatever Echo is used for), then the server can issue Echo values that do not need to be (nit) I'd suggest "whatever Echo is being used for" (add "being") In most other cases, there are properties extracted of which the server is the authority ("The request must not be older than five minutes" is counted on the server's clock, not the client's) or which [If my above suggestion is used, that removes the word "extracted", this use of "extracted" should probably be reworded as well.] Section 3.5.1 When security services are provided by DTLS, this can only be confirmed if there was no CoAP retransmission of the request, the request was responded to, and the server performs replay protection. (nit) I think the server would either "perform replay detection" or "[provide/use] replay protection" -- performing protection is not a common phrasing. way, the server can rely on a conforming client to set the Request- Tag option when required, and thereby have confidence the integrity of the assembled body. (nit) "have confidence in" Appendix A This method is suitable both for time and for event base freshness (e.g. by clearing the cache when an event occurs), and independent of the client authority. (nit) "for time- and for event-based freshness" (and again a couple paragraphs later) |
2021-08-30
|
13 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2021-07-20
|
13 | Francesca Palombini | [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini |
2021-07-12
|
13 | (System) | Removed all action holders (IESG state changed) |
2021-07-12
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-07-12
|
13 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-13.txt |
2021-07-12
|
13 | (System) | New version approved |
2021-07-12
|
13 | (System) | Request for posting confirmation emailed to previous authors: Christian Amsuess , Goeran Selander , John Mattsson |
2021-07-12
|
13 | Christian Amsüss | Uploaded new revision |
2021-03-10
|
12 | Cindy Morgan | Shepherding AD changed to Francesca Palombini |
2021-02-19
|
12 | Barry Leiba | Waiting for author responses to IESG comments, especially comments from Roman and Ben. |
2021-02-19
|
12 | (System) | Changed action holders to John Preuß Mattsson, Göran Selander, Christian Amsüss (IESG state changed) |
2021-02-19
|
12 | Barry Leiba | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2021-02-18
|
12 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2021-02-18
|
12 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2021-02-18
|
12 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-02-18
|
12 | Murray Kucherawy | [Ballot comment] There are several SHOULDs (e.g., near the top of page 8, and again at the end of Section 2.3) that left me wondering … [Ballot comment] There are several SHOULDs (e.g., near the top of page 8, and again at the end of Section 2.3) that left me wondering why an implementer would do something other than what it says. Since SHOULD offers a choice, some advice would be helpful here. Otherwise, maybe those ought to be MUSTs. I suggest giving them all a once-over to see if any such advice would be helpful to include. |
2021-02-18
|
12 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-02-17
|
12 | Benjamin Kaduk | [Ballot comment] Thank you for working on this document; these mechanisms are important and will help fill some long-standing gaps in CoAP operation. That said, … [Ballot comment] Thank you for working on this document; these mechanisms are important and will help fill some long-standing gaps in CoAP operation. That said, I do have some fairly substantive comments that might result in significant text changes. While I recognize that there is going to be a spectrum of requirements for determining freshness, I would have expected the far extreme of that spectrum to include a strongly time-limited single-use cryptographic nonce (akin to what the ACME protocol of RFC 8555 uses but with time limit), as well as discussion of some points on the spectrum and which ones might be more or less appropriate in various cases. I do see some discussion of different use cases, but not much about the tradeoffs along the spectrum, and no discussion at all about the strongest properties that it is possible to obtain with this mechanism. In several places we mention that the Echo option enables a server to "synchronize state", which to me is a confusing or misleading characterization -- as I understand it, both additional (application) protocol mechanism and constraints are required in order for state synchronization to occur. Specifically, the client has to be the authority for the state in question, and the application protocol needs to specifically indicate under what conditions and which state is to be synchronized. In essence, the Echo option provides a mechanism for ensuring request freshness, and that mechanism is leveraged by the application protocol to make a synchronzed transfer of state from client to server. But AFAICT it is not a generic state synchronization mechanism, the state to be synchronized is not conveyed in the option body, etc. My preference would be to take "synchronize state" out of the primary list of what is possible and mention it in a separate sentence as something that can be constructed using the functionality that the Echo option provides. There are a couple places where we recommend (implicitly or explicitly) a sequential counter in contexts that might otherwise use a randomized value. I think I mention them all in my section-by-section comments, but in general the sequential counter might be placing too strong a requirement on the value, and the considerations of draft-gont-numeric-ids-sec-considerations seem relevant. I think it would also be enlightening to have a comparison between the anti-replay/freshness properties provided by the optional DTLS replay protection mechanism and the Echo option. I know they have differences, but I think there is also some commonality, and giving readers guidance on whether one vs the other suffices or both are needed could be useful. Section 2.3 Upon receiving a 4.01 Unauthorized response with the Echo option, the client SHOULD resend the original request with the addition of an Echo option with the received Echo option value. [...] [just noting that IIUC the revised requirements on token generation made later in this document are needed in order for this "resend the original request" to be safe" ... I am not sure if it needs to be called out here specifically, though.] > The cache values MUST be different for all practical purposes. Since we're at least advocating using crypto to enforce this property, I think that "execpt with negligible probability" would be a more conventional expression than "for all practical purposes". I don't think the example of this in Figure 3 meets the requirements, though, since the echo option value is just a counter that is easily spoofable. [...] When used to demonstrate reachability at a claimed network address, the Echo option SHOULD contain the client's network address, but MAY be unprotected. What does "contain" mean, here? Plaintext? That seems potentially problematic; using it as an input to the MAC that is not transmitted (as I mention later) is more conventional, in my understanding. The CoAP client side of HTTP-to-CoAP proxies SHOULD respond to Echo challenges themselves if they know from the recent establishing of the connection that the HTTP request is fresh. Otherwise, they SHOULD respond with 503 Service Unavailable, Retry-After: 0 and terminate any underlying Keep-Alive connection. If the HTTP request arrived in Early Data, the proxy SHOULD use a 425 Too Early response instead (see [RFC8470]). They MAY also use other mechanisms to establish freshness of the HTTP request that are not specified here. Where is the MUST-level requirement to actually ensure freshness (by whatever mechanism is available/appropriate)? Section 2.4 * The same Echo value may be used for multiple actuation requests to the same server, as long as the total round-trip time since the Echo option value was generated is below the freshness threshold. The "round-trip" in "total round-trip time" is a bit confusing to me, since what's being described doesn't really seem like a round-trip operation, rather a "get a thing, do some stuff, do some more stuff, keep sending the echo option, send a particular request to the server that we are talking about checking the freshness of", with the final request not very correlated to the issuance event. 2. A server may use the Echo option to synchronize properties (such as state or time) with a requesting client. A server MUST NOT synchronize a property with a client which is not the authority of the property being synchronized. E.g. if access to a server resource is dependent on time, then server MUST NOT synchronize time with a client requesting access unless it is time authority for the server. Also, disambiguating the final "it" seems like it would be worthwhile, just in case, since this is rather important to get right. * If a server reboots during operation it may need to synchronize state or time before continuing the interaction. For example, with OSCORE it is possible to reuse a partly persistently stored security context by synchronizing the Partial IV (sequence number) using the Echo option, see Section 7.5 of [RFC8613]. In light of my toplevel comment, I'd suggest rewording this to clarify that the protocol specified in RFC 8613 includes a mechanism for resynchronizing the partial IV state, that uses the Echo option in a specific controlled protocol interaction. (A similar consideration would apply to the group communication example, though it might be a little harder to write clearly.) 3. A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks such as described in Section 11.3 of [RFC7252] (where an attacker would put a victim's address in the source address of a CoAP request). The RECOMMENDED way to do this is to ask a client to Echo its request to verify its source address. [...] (editorial) this usage of "ask a client to Echo its request" seems rather divorced from the actual mechanicis of the Echo option...in the rest of the document (bar one other instance noted below) we restrain ourselves to saying that the Echo option is what is echoed, divorced from the containing request/response. This needs to be done only once per peer [...] How is the "peer" identified in this case? Is it tied to a single (security) association, or the identity (if any) associated with that security association, or IP address (and port?), or something else? How long can/should the reachability information be cached for? reachability as described in Section 2.3. The proxy MAY forward idempotent requests immediately to have a cached result available when the client's Echoed request arrives. (The "Echoed request" phrasing again.) Section 3.1 In order for a security protocol to support CoAP operations over unreliable transports, it must allow out-of-order delivery of messages using e.g. a sliding replay window such as described in Section 4.1.2.6 of DTLS ([RFC6347]). My understanding is that the requirement is only to allow out-of-order delivery of messages (not necessarily including replay detection), so the clause about the sliding window is not needed. here. Section 3.2 In essence, it is an implementation of the "proxy-safe elective option" used just to "vary the cache key" as suggested in [RFC7959] Section 2.4. The referenced section of RFC 7959 covers Block2 operation, but my understanding is that the Block1 operation (covered in Section 2.5 of that same document) would be a more applicable reference. Section 3.3 Also, a client that lost interest in an old operation but wants to start over can overwrite the server's old state with a new initial (num=0) Block1 request and the same Request-Tag under some circumstances. Likewise, that results in the new message not being part of the old operation. Where are those "some circumstances" enumerated? Section 3.5.1 If any future security mechanisms allow a block-wise transfer to continue after an endpoint's details (like the IP address) have changed, then the client MUST consider messages sent to _any_ endpoint address using the new operation's security context. (editorial?) when I read this I feel like it's missing a clause -- consider those messages for the purposes of what operation? * The client MUST NOT regard a block-wise request operation as concluded unless all of the messages the client previously sent in the operation have been confirmed by the message integrity protection mechanism, [...] nit: confirmed as what? Delivered? Typically, in OSCORE, these confirmations can result either from nit: I suggest "When security services are provided by OSCORE, these confirmations typically result from" In DTLS, this can only be confirmed if the request message was not retransmitted, and was responded to. Similarly, this would be "When security services are provided by DTLS" -- DTLS does include a native retransmission layer, but only for DTLS handshake messages, so this phrasing is needlessly ambiguous as to whether it is the CoAP request that got retransmitted. Authors of other documents (e.g. applications of [RFC8613]) are invited to mandate this behavior for clients that execute block-wise interactions over secured transports. In this way, the server can rely on a conforming client to set the Request-Tag option when required, and thereby conclude on the integrity of the assembled body. Could you clarify which client behavior would be mandated? The overall "body integrity based on payload integrity" procedures, or the specific "typically, in OSCORE" behavior? Also (nit), the phrasing "conclude on the integrity of" seems unusual to me; I think the intent is more like "thereby have confidence in the integrity of". Section 3.5.2 For those cases, Request-Tag is the proxy-safe elective option suggested in [RFC7959] Section 2.4 last paragraph. (Per above, Section 2.5?) Section 3.6 The Request-Tag option is repeatable because this easily allows several cascaded stateless proxies to each put in an origin address. They can perform the steps of Section 3.5.3 without the need to create an option value that is the concatenation of the received option and their own value, and can simply add a new Request-Tag option unconditionally. Thanks for including this! However, it wasn't clear to me from reading https://tools.ietf.org/html/rfc7252#section-5.4.5 and this document whether the order of repeated Request-Tag options was significant. Some clarification might be helpful. Section 3.7 That approach would have been difficult to roll out reliably on DTLS where many implementations do not expose sequence numbers, and would still not prevent attacks like in [I-D.mattsson-core-coap-actuators] Section 2.5.2. (I agree that DTLS implementations largely don't expose sequence numbers and that is unlikely to change. But) I am not sure I fully understand the scenario referenced in draft-mattsson-core-coap-actuators §2.5.2. Perhaps it is not what was intended to be conveyed, but it seems like in a setup that is tracking both sequence and fragment numbers, it would be pretty easy to enforce that a fragment-0 block will only start a new request if the sequence number is larger than the sequence number of the current/previous blockwise request. IIUC that would reject the "withheld first block" as being too old. Section 3.8 and MUST NOT use the same ETag value for different representations of a resource. (side note) I was a little surprised that this was not already a requirement, but I couldn't find an equivalent statement in a quick review of RFC 7252. (It's definitely correct that this is required behavior to get the protection in question.) Section 4.1 In HTTPS, this type of binding is always assured by the ordered and reliable delivery as well as mandating that the server sends responses in the same order that the requests were received. [...] I believe this description applies to HTTP/1.1 over TLS, but not to HTTP/2 or HTTP/3 (both of which provide other mechanisms for reliably binding requests and responses in the form of stream IDs). Section 4.2 One easy way to accomplish this is to implement the Token (or part of the Token) as a sequence number starting at zero for each new or rekeyed secure connection. This approach SHOULD be followed. I note that sequential assignment often has some additional undesirable properties, as discussed in draft-gont-numeric-ids-sec-considerations. Would a different method (e.g., one listed in draft-irtf-pearg-numeric-ids-generation) provide the needed properties with fewer side effects? In particular, sequential increment is at odds with the "nontrivial, randomized token" recommended for clients not using TLS (that is intended to guard against spoofing of responses). ("use of a sequence number" and "a sequence number approach" also appear in §5.1, if this is changed.) Section 5 The freshness assertion of the Echo option comes from the client reproducing the same value of the Echo option in a request as in a previous response. [...] nit/editorial: I suggest s/as in/as it received in/ However, this may not be an issue if the communication is integrity protected against third parties and the client is trusted not misusing this capability. [...] nit: s/trusted not misusing/trusted to not misuse/ See ([RFC8613], Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory. nit: redundant word in "solution approaches"? For the purpose of generating timestamps for Echo a server MAY set a timer at reboot and use the time since reboot, in a unit such that different requests arrive at different times. [...] Something about this sentence confuses me, possibly around "in a unit". Section 5.1 Tokens that cannot be reused need to be handled appropriately. This could be solved by increasing the Token as soon as the currently used Token cannot be reused, or by keeping a list of all blacklisted Tokens. editorial: perhaps "unsafe to reuse" is more clear than "blacklisted"? Section 6 This seems to be the first (and only) place where we use the term "preemptive Echo values"; it might be worth a bit more exposition that these are ones piggybacked on non-4.01 responses (assuming that's correct, of course). Section 8.1 I note that DTLS 1.3 is in IETF Last Call. I did not notice anything in this document that's specific to a DTLS version, which suggests that it woudl be safe to change the reference according to relative publication order of these documents. It would be good for the authors to confirm that at their leisure, so as to not be rushed into a decision if/when the RFC Editor asks during their processing. Section 8.2 I note that draft-mattsson-core-coap-actuators is referenced from several locations (for useful additional discussion, to be clear), but it is only an individual draft that expired almost two years ago. Is there any likelihood that it will ever progress to an RFC? One might argue that "SHOULD use a 425 Too Early response" is enough to promote RFC 8470 to being a normative reference (see https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/). Section A 2. Integrity Protected Timestamp. The Echo option value is an integrity protected timestamp. The timestamp can have different resolution and range. A 32-bit timestamp can e.g. give a resolution of 1 second with a range of 136 years. The (pseudo-)random secret key is generated by the server and not shared with any other party. The use of truncated HMAC-SHA-256 is RECOMMENDED. With a 32-bit timestamp and a 64-bit MAC, the size of the Echo option value is 12 bytes and the Server state is small and constant. The security against an attacker guessing echo values is given by the MAC length. If the server loses time continuity, e.g. due to reboot, the old key MUST be deleted and replaced by a new random secret key. Note that the privacy considerations in Section 6 may apply to the timestamp. Therefore, it might be important to encrypt it. Depending on the choice of encryption algorithms, this may require a nonce to be included in the Echo option value. I note that a MAC construction allows additional information to be covered under the MAC that is not sent alongside it, e.g., identity information about the client to which the Echo option value is being associated. Are there common situations in which including such additional contextual information under the MAC would be valuable (to prevent an echo option value received on one connection from being usable on a different one)? 3. Persistent Counter. This is an event-based freshness method usable for state synchronization (for example after volatile state has been lost), and cannot be used for client aliveness. It requires that the client can be trusted to not spuriously produce Echo values. I have severe qualms about specifying a protocol mechcanism that relies on trusting a client to this extent. It seems to expose a lot of latent risk; even if we think there should be mechanisms in place to protect against that risk, they might fail, or the mechanism might get used outside its intended context, etc.; if there are other mechanisms available for similar cost that provide the needed properties it seems more robust to suggest their use in place of the persistent counter. |
2021-02-17
|
12 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-02-17
|
12 | Warren Kumari | [Ballot comment] Much thanks to Juergen Schoenwaelder for the OpsDir review, and the authors for addressing the comments... It's a good and easy read. |
2021-02-17
|
12 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-02-17
|
12 | Roman Danyliw | [Ballot comment] Thank you for writing this mitigation for draft-mattsson-core-coap-actuators. ** Section 5. Per “As each pseudorandom number most only be used once …”, how … [Ballot comment] Thank you for writing this mitigation for draft-mattsson-core-coap-actuators. ** Section 5. Per “As each pseudorandom number most only be used once …”, how will that be possible when echo values as small are 1-byte are possible? ** Section 5. However, this may not be an issue if the communication is integrity protected against third parties and the client is trusted not misusing this capability. -- Why is the use of integrity presented as only a possibility here? Didn’t Section 2.3 require it when assuring the freshness requirement – “When used to serve freshness requirements including client aliveness and state synchronizing), the Echo option value MUST be integrity protected between the intended endpoints ...” -- Would it be clearer here to say that this is mitigation against an on-path attacker, not against rogue/compromised clients? ** Appendix A helpfully tries to lay out recommendations. A few comments: -- all of the recommendations here have option values much larger than the permitted minimum of 1-byte. In addition to the recommendations, could the circumstances of the lower bound also be discussed -- it would be helpful to explicitly state which methods apply to the specific use cases (client aliveness, request freshness, state synchronization, network address reachability). For example, method 3 (persistent counter) notes that it can be used for state synchronization but not client aliveness |
2021-02-17
|
12 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-02-16
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-02-16
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2021-02-16
|
12 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated). Eliot Lear … [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated). Eliot Lear (in copy) has also reviewed the document as IoT directorate reviewer at: https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-12-iotdir-telechat-lear-2021-02-05/ So, please address/reply to his comment. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2.2 -- "The Echo option value is a challenge from the server to the client..." Just wondering whether "echo" is the right choice for the option as it is too close to ICMP_ECHO_REQUEST, why not "challenge" ? I would have expected some statements related to non-idempotent requests (generic statement) and then specific examples such as actuators. -- Section 2.2.1 -- Are the authors confident enough to state a minimum length of 1 octet ? If the intent of the document is to prevent replay attack, then I wonder whether one octet is enough... Unsure whether Section 5 (security considerations) addresses this issue correctly. |
2021-02-16
|
12 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-02-15
|
12 | Erik Kline | [Ballot comment] [[ nits ]] [ section 2.4 ] * "causing overheads" -> "causing overhead" |
2021-02-15
|
12 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-02-15
|
12 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2021-02-10
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-02-05
|
12 | Martin Duke | [Ballot comment] 5.1 This is optional, but please replace "blacklisted" with "deny-listed". 6. What is a "preemptive" echo value? |
2021-02-05
|
12 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-02-05
|
12 | Eliot Lear | Request for Telechat review by IOTDIR Completed: Ready with Issues. Reviewer: Eliot Lear. Sent review to list. |
2021-02-05
|
12 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Eliot Lear |
2021-02-05
|
12 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Eliot Lear |
2021-02-05
|
12 | Ines Robles | Assignment of request for Telechat review by IOTDIR to Henk Birkholz was rejected |
2021-02-02
|
12 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Henk Birkholz |
2021-02-02
|
12 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Henk Birkholz |
2021-02-02
|
12 | Éric Vyncke | Requested Telechat review by IOTDIR |
2021-02-01
|
12 | Cindy Morgan | Placed on agenda for telechat - 2021-02-18 |
2021-02-01
|
12 | Barry Leiba | Ballot has been issued |
2021-02-01
|
12 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2021-02-01
|
12 | Barry Leiba | Created "Approve" ballot |
2021-02-01
|
12 | Barry Leiba | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2021-02-01
|
12 | Marco Tiloca | ### Summary Document Shepherd: Marco Tiloca Area Director: Barry Leiba The document considers the following security issues when using the CoAP protocol, even if together … ### Summary Document Shepherd: Marco Tiloca Area Director: Barry Leiba The document considers the following security issues when using the CoAP protocol, even if together with a security protocol. These are especially severe in use cases involving actuators. 1. A server receiving a request is in general not able to verify when the client generated the request, which can be delayed or not fresh. This can further result in amplification attacks. 2. When using block-wise transfer, the integrity protection of a block does not extend to the whole request body. Interchanged blocks between different message bodies to the same resource may go undetected, so endangering multiple concurrent block-wise transfers. 3. A client may erroneously associate the wrong response to a request. The document addresses the issues (1)(2) by defining the usage of two new CoAP options, namely Echo and Request-Tag; as well as the issue (3) by updating RFC 7252 to forbid non-secure reuse of Tokens in CoAP. The document updates RFC 7252 also with respect to amplification mitigation, for which it recommends the use of the new Echo option. The document is intended for Standards Track. Version -12 addressed Last Call comments from GenART, TSVART and OpsDir, about providing clarifications and small fixes. ### Review and Consensus The document has been discussed on multiple IETF meetings, and has gone through multiple expert reviews. Consensus has been reached on the content of this document and its need. ### Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. ### Other Points The document registers two new option numbers in the "CoAP Option Numbers" registry defined by RFC 7252, and provides detailed reasoning for the suggested values. ### Checklist - [x] Does the shepherd stand behind the document and think the document is ready for publication? - [x] Is the correct RFC type indicated in the title page header? - [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary? - [x] Is the intent of the document accurately and adequately explained in the introduction? - [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? - [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? 'Note: There are 10 lines having 2 characters in excess each (see tables in Figure 1 and Figure 4). Their length will become within the limit when the RFC editor replaces the TBDxxx numbers with the ones assigned by IANA.' - [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? - [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? - [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? - [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? - [x] If this is a "bis" document, have all of the errata been considered? 'Does not apply' **IANA** Considerations: - [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. - [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? - [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? - [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? - [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? - [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? 'Does not apply' - [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? 'Does not apply' |
2021-02-01
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-02-01
|
12 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-12.txt |
2021-02-01
|
12 | (System) | New version approved |
2021-02-01
|
12 | (System) | Request for posting confirmation emailed to previous authors: Christian Amsuess , Goeran Selander , John Mattsson |
2021-02-01
|
12 | Christian Amsüss | Uploaded new revision |
2021-02-01
|
12 | Christian Amsüss | Uploaded new revision |
2020-12-10
|
11 | Amanda Baber | IANA Experts State changed to Expert Reviews OK |
2020-12-10
|
11 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2020-12-03
|
11 | Barry Leiba | Waiting for responses to GenART, TSVART, and OpsDir reviews. |
2020-12-03
|
11 | Barry Leiba | IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead |
2020-12-02
|
11 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-12-02
|
11 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-core-echo-request-tag-11. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-core-echo-request-tag-11. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that upon approval of this document, there is a single action for IANA. In the CoAP Option Numbers registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at https://www.iana.org/assignments/core-parameters/ two new option numbers are to be registered: Number: [ TBD-at-Registration ] Name: Echo Reference: [ RFC-to-be ] Number: [ TBD-at-Registration ] Name: Request-Tag Reference: [ RFC-to-be ] IANA notes that the authors of the current draft suggest the value 252 for Echo and 292 for Request-Tag. Both values are currently available, and IANA will attempt to comply with the wishes of the authors. However, value 292 is in the region of the registry governed by Specification Required (as defined by RFC 8126). If that value is to be used, we will initiate the required expert review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." It should be noted that if the AD agrees and the WG chairs want to submit a request (to iana@iana.org) in accordance with RFC 7120, there is an early allocation process available for both values. An early allocation in the Specification Required range would still require expert approval. Thank you, Amanda Baber Lead IANA Services Specialist |
2020-12-02
|
11 | Ines Robles | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Ines Robles. Sent review to list. |
2020-12-02
|
11 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2020-12-01
|
11 | Joerg Ott | Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Joerg Ott. Sent review to list. |
2020-11-30
|
11 | Jürgen Schönwälder | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jürgen Schönwälder. Sent review to list. |
2020-11-25
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2020-11-25
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2020-11-23
|
11 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Joerg Ott |
2020-11-23
|
11 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Joerg Ott |
2020-11-21
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2020-11-21
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2020-11-19
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2020-11-19
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2020-11-18
|
11 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-11-18
|
11 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-12-02): From: The IESG To: IETF-Announce CC: marco.tiloca@ri.se, core-chairs@ietf.org, Marco Tiloca , core@ietf.org, … The following Last Call announcement was sent out (ends 2020-12-02): From: The IESG To: IETF-Announce CC: marco.tiloca@ri.se, core-chairs@ietf.org, Marco Tiloca , core@ietf.org, barryleiba@gmail.com, draft-ietf-core-echo-request-tag@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (CoAP: Echo, Request-Tag, and Token Processing) to Proposed Standard The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'CoAP: Echo, Request-Tag, and Token Processing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-12-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with a security protocol, and with respect to amplification mitigation, where the use of Echo is now recommended. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ No IPR declarations have been submitted directly on this I-D. |
2020-11-18
|
11 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-11-18
|
11 | Barry Leiba | Last call was requested |
2020-11-18
|
11 | Barry Leiba | Last call announcement was generated |
2020-11-18
|
11 | Barry Leiba | Ballot approval text was generated |
2020-11-18
|
11 | Barry Leiba | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-11-02
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-11-02
|
11 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-11.txt |
2020-11-02
|
11 | (System) | New version approved |
2020-11-02
|
11 | (System) | Request for posting confirmation emailed to previous authors: Goeran Selander , Christian Amsuess , John Mattsson |
2020-11-02
|
11 | Christian Amsüss | Uploaded new revision |
2020-11-02
|
11 | Christian Amsüss | Uploaded new revision |
2020-09-10
|
10 | Marco Tiloca | Changed document external resources from: [] to: github_repo https://github.com/core-wg/echo-request-tag (Working Group Repo) |
2020-08-03
|
10 | Barry Leiba | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2020-08-03
|
10 | Barry Leiba | Ballot writeup was changed |
2020-08-03
|
10 | Barry Leiba | IESG state changed to AD Evaluation from Publication Requested |
2020-08-03
|
10 | Marco Tiloca | ### Summary Document Shepherd: Marco Tiloca Area Director: Barry Leiba The document considers the following security issues when using the CoAP protocol, even if together … ### Summary Document Shepherd: Marco Tiloca Area Director: Barry Leiba The document considers the following security issues when using the CoAP protocol, even if together with a security protocol. These are especially severe in use cases involving actuators. 1. A server receiving a request is in general not able to verify when the client generated the request, which can be delayed or not fresh. This can further result in amplification attacks. 2. When using block-wise transfer, the integrity protection of a block does not extend to the whole request body. Interchanged blocks between different message bodies to the same resource may go undetected, so endangering multiple concurrent block-wise transfers. 3. A client may erroneously associate the wrong response to a request. The document addresses the issues (1)(2) by defining the usage of two new CoAP options, namely Echo and Request-Tag; as well as the issue (3) by updating RFC 7252 to forbid non-secure reuse of Tokens in CoAP. The document updates RFC 7252 also with respect to amplification mitigation, for which it recommends the use of the new Echo option. The document is intended for Standards Track. ### Review and Consensus The document has been discussed on multiple IETF meetings, and has gone through multiple expert reviews. Consensus has been reached on the content of this document and its need. ### Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. ### Other Points The document registers two new option numbers in the "CoAP Option Numbers" registry defined by RFC 7252, and provides detailed reasoning for the suggested values. ### Checklist - [x] Does the shepherd stand behind the document and think the document is ready for publication? - [x] Is the correct RFC type indicated in the title page header? - [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary? - [x] Is the intent of the document accurately and adequately explained in the introduction? - [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? - [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? 'Note: There are 10 lines having 2 characters in excess each (see tables in Figure 1 and Figure 4). Their length will become within the limit when the RFC editor replaces the TBDxxx numbers with the ones assigned by IANA.' - [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? - [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? - [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? - [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? - [x] If this is a "bis" document, have all of the errata been considered? 'Does not apply' **IANA** Considerations: - [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. - [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? - [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? - [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? - [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? - [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? 'Does not apply' - [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? 'Does not apply' |
2020-08-03
|
10 | Marco Tiloca | Responsible AD changed to Barry Leiba |
2020-08-03
|
10 | Marco Tiloca | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-08-03
|
10 | Marco Tiloca | IESG state changed to Publication Requested from I-D Exists |
2020-08-03
|
10 | Marco Tiloca | IESG process started in state Publication Requested |
2020-08-03
|
10 | Marco Tiloca | ### Summary Document Shepherd: Marco Tiloca Area Director: Barry Leiba The document considers the following security issues when using the CoAP protocol, even if together … ### Summary Document Shepherd: Marco Tiloca Area Director: Barry Leiba The document considers the following security issues when using the CoAP protocol, even if together with a security protocol. These are especially severe in use cases involving actuators. 1. A server receiving a request is in general not able to verify when the client generated the request, which can be delayed or not fresh. This can further result in amplification attacks. 2. When using block-wise transfer, the integrity protection of a block does not extend to the whole request body. Interchanged blocks between different message bodies to the same resource may go undetected, so endangering multiple concurrent block-wise transfers. 3. A client may erroneously associate the wrong response to a request. The document addresses the issues (1)(2) by defining the usage of two new CoAP options, namely Echo and Request-Tag; as well as the issue (3) by updating RFC 7252 to forbid non-secure reuse of Tokens in CoAP. The document updates RFC 7252 also with respect to amplification mitigation, for which it recommends the use of the new Echo option. The document is intended for Standards Track. ### Review and Consensus The document has been discussed on multiple IETF meetings, and has gone through multiple expert reviews. Consensus has been reached on the content of this document and its need. ### Intellectual Property Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG. ### Other Points The document registers two new option numbers in the "CoAP Option Numbers" registry defined by RFC 7252, and provides detailed reasoning for the suggested values. ### Checklist - [x] Does the shepherd stand behind the document and think the document is ready for publication? - [x] Is the correct RFC type indicated in the title page header? - [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary? - [x] Is the intent of the document accurately and adequately explained in the introduction? - [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed? - [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? 'Note: There are 10 lines having 2 characters in excess each (see tables in Figure 1 and Figure 4). Their length will become within the limit when the RFC editor replaces the TBDxxx numbers with the ones assigned by IANA.' - [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79? - [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified? - [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state? - [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? - [x] If this is a "bis" document, have all of the errata been considered? 'Does not apply' **IANA** Considerations: - [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions. - [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries? - [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)? - [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries? - [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call? - [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives? 'Does not apply' - [x] Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified? 'Does not apply' |
2020-08-03
|
10 | Marco Tiloca | Changed consensus to Yes from Unknown |
2020-08-03
|
10 | Marco Tiloca | Intended Status changed to Proposed Standard from None |
2020-07-25
|
10 | Marco Tiloca | Added to session: IETF-108: core Tue-1410 |
2020-07-13
|
10 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-10.txt |
2020-07-13
|
10 | (System) | New version approved |
2020-07-13
|
10 | (System) | Request for posting confirmation emailed to previous authors: Goeran Selander , John Mattsson , Christian Amsuess |
2020-07-13
|
10 | Christian Amsüss | Uploaded new revision |
2020-07-13
|
10 | Christian Amsüss | Uploaded new revision |
2020-05-04
|
09 | Marco Tiloca | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2020-03-09
|
09 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-09.txt |
2020-03-09
|
09 | (System) | New version approved |
2020-03-09
|
09 | (System) | Request for posting confirmation emailed to previous authors: John Mattsson , Christian Amsuess , Goeran Selander |
2020-03-09
|
09 | Christian Amsüss | Uploaded new revision |
2020-03-09
|
09 | Christian Amsüss | Uploaded new revision |
2020-03-09
|
08 | Jaime Jimenez | Added -08 to session: IETF-107: core Tue-1550 |
2020-03-09
|
08 | Carsten Bormann | Notification list changed to Marco Tiloca <marco.tiloca@ri.se> |
2020-03-09
|
08 | Carsten Bormann | Document shepherd changed to Marco Tiloca |
2019-11-04
|
08 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-08.txt |
2019-11-04
|
08 | (System) | New version accepted (logged-in submitter: Christian Amsüss) |
2019-11-04
|
08 | Christian Amsüss | Uploaded new revision |
2019-09-19
|
07 | John Preuß Mattsson | New version available: draft-ietf-core-echo-request-tag-07.txt |
2019-09-19
|
07 | (System) | New version approved |
2019-09-19
|
07 | (System) | Request for posting confirmation emailed to previous authors: Christian Amsuess , John Mattsson , Goeran Selander |
2019-09-19
|
07 | John Preuß Mattsson | Uploaded new revision |
2019-09-18
|
06 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-06.txt |
2019-09-18
|
06 | (System) | New version approved |
2019-09-18
|
06 | (System) | Request for posting confirmation emailed to previous authors: Christian Amsuess , John Mattsson , Goeran Selander |
2019-09-18
|
06 | Christian Amsüss | Uploaded new revision |
2019-09-18
|
06 | Christian Amsüss | Uploaded new revision |
2019-07-02
|
05 | Carsten Bormann | Till 2019-07-10. |
2019-07-02
|
05 | Carsten Bormann | IETF WG state changed to In WG Last Call from WG Document |
2019-05-06
|
05 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-05.txt |
2019-05-06
|
05 | (System) | New version approved |
2019-05-06
|
05 | (System) | Request for posting confirmation emailed to previous authors: Christian Amsuess , John Mattsson , Goeran Selander |
2019-05-06
|
05 | Christian Amsüss | Uploaded new revision |
2019-03-23
|
04 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-04.txt |
2019-03-23
|
04 | (System) | New version approved |
2019-03-23
|
04 | (System) | Request for posting confirmation emailed to previous authors: Christian Amsuess , John Mattsson , Goeran Selander |
2019-03-23
|
04 | Christian Amsüss | Uploaded new revision |
2018-10-22
|
03 | Göran Selander | New version available: draft-ietf-core-echo-request-tag-03.txt |
2018-10-22
|
03 | (System) | New version approved |
2018-10-22
|
03 | (System) | Request for posting confirmation emailed to previous authors: Christian Amsuess , John Mattsson , Goeran Selander |
2018-10-22
|
03 | Göran Selander | Uploaded new revision |
2018-06-29
|
02 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-02.txt |
2018-06-29
|
02 | (System) | New version approved |
2018-06-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Christian Amsuess , John Mattsson , Goeran Selander |
2018-06-29
|
02 | Christian Amsüss | Uploaded new revision |
2018-06-29
|
02 | Christian Amsüss | Uploaded new revision |
2018-03-05
|
01 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-01.txt |
2018-03-05
|
01 | (System) | New version approved |
2018-03-05
|
01 | (System) | Request for posting confirmation emailed to previous authors: John Mattsson , Goeran Selander , core-chairs@ietf.org, Christian Amsuess |
2018-03-05
|
01 | Christian Amsüss | Uploaded new revision |
2018-03-05
|
01 | Christian Amsüss | Uploaded new revision |
2018-03-05
|
01 | (System) | Request for posting confirmation emailed to previous authors: John Mattsson , Goeran Selander , core-chairs@ietf.org, Christian Amsuess |
2018-03-05
|
01 | Christian Amsüss | Uploaded new revision |
2018-03-05
|
01 | Christian Amsüss | Uploaded new revision |
2017-10-31
|
00 | Carsten Bormann | This document now replaces draft-amsuess-core-repeat-request-tag instead of None |
2017-10-30
|
00 | Christian Amsüss | New version available: draft-ietf-core-echo-request-tag-00.txt |
2017-10-30
|
00 | (System) | WG -00 approved |
2017-10-30
|
00 | Christian Amsüss | Set submitter to "=?utf-8?q?Christian_Ams=C3=BCss?= " and sent approval email to group chairs: core-chairs@ietf.org |
2017-10-30
|
00 | Christian Amsüss | Uploaded new revision |