Draft: draft-ietf-core-echo-request-tag

Commentary: ... and clarify that client aliveness is a cryptographic property . This is in response to comments about the conflict between " OSCORE servers MUST ONLY produce Inner " and " Echo option [ ... ] MAY be unprotected " . Contributes - To : 
 Sounds good . 
 I just noticed there as on this stack as well and ( hopefully ) simplified that into , please have a look there . 
 Good , looks like an improvement . 
 “ CoAP - to - CoAP proxy MAY set an Echo option on responses , both on forwarded ones that had no Echo option or ones generated by the proxy ( from cache or as an error ) . ” I assume a proxy having a cache can generate it ’s own requests as well . In these cases the proxy should be allowed to behave like any other client . The current text “ However , it MUST relay the Echo option of responses unmodified ” kind of give the idea that proxys can not remove the Echo values . 
 ( from today 's telco ) " client aliveness " questions lead to the question of who is the client , and from there to which endpoints are involved . From  's endpoint definition , the security association is part of it . So there are two endpoints involved , the hop - by - hop endpoint ( which has no security , or possibly the security of a wrapping DTLS connection ) and the end - to - end endpoint ( which is OSCORE protected ) , which may or may not reside on the same host . Different positions of the Echo option relate to communication with different endpoints . It 'd be easier to describe the Echo option behavior if that distinction were made explicit in OSCORE , and I do n't want to introduce too much of new concepts in here where they do n't belong -- finding text to address that might be tricky . ( Once words are found to describe that in the Echo text , we 'll also have the words to talk about the independent alivenesses of the endpoints , and say that for cryptographically showing " client aliveness " ( that 's a term there ) , the aliveness of the inner endpoint must be shown ) . 
 I 've written up to address the issue we received comments on . On the topic of endpoints , I found that the text already clearly separates the use case of " client aliveness " and " network reachability " ; I 've a word on the aliveness being a cryptographic property and not just another word for the network address being in service , which is hopefully enough for the confusion that has arisen . No need to make things more complicated by pointing out the two server endpoints that are still around there : we never talk of properties that either can have ( client aliveness is about the protected endpoint , network reachability is about the unprotected one ) . If you 're happy with , I think we can close this . 
 Taken care of with
Paragraph (version A):
A CoAP-to-CoAP proxy MAY respond to requests with 4.01 with an Echo
option to ensure the client's reachability at its claimed address,
and MUST remove the Echo option it recognizes as one generated by
itself on follow-up requests.  However, it MUST relay the Echo option
of responses unmodified, and MUST relay the Echo option of requests
it does not recognize as generated by itself unmodified.
Paragraph (version B):
CoAP-to-CoAP proxy MAY respond to requests with an Echo option, but
MUST remove the Echo option it recognizes as one generated by itself
on follow-up requests.  However, it MUST relay the Echo option of
responses unmodified, and MUST relay the Echo option of requests it
does not recognize as generated by itself unmodified.  A CoAP-to-CoAP
proxy MAY however add an Echo Option to a response that does not have
an Echo Option.