Re: [dtn] [EXT] Fwd: New Version Notification for draft-gomez-core-coap-bp-00.txt

[Carles Gomez Montenegro <[e-mail]>]

Hello Brian,

Thanks for your valuable feedback.

Yes, definitely, this is something that needs to be addressed in the draft.

The current version of the draft does not yet include security-related
content, but we will aim to incorporate your feedback in a future update.
As you detail, there are several aspects that need to be properly
considered.

We will reply back with some proposal intended to address the points you
raise below.

Best regards,

Carles (on behalf of the authors)





On Wed, 20 Mar 2024 at 06:36, Sipos, Brian J. <[e-mail]>
wrote:

> Carles,
>
> Great to see your feedback.
>
>
>
> One other aspect to consider with the application-level responses is that
> of security parity between request and response bundles and/or ADUs. It’s
> likely that the security (and forwarding) policies related to status
> reports will be completely disconnected from application traffic being
> statused, in the sense that the status reports have a different
> destination/audience by design.
>
>
>
> On that same topic it would be good to have some application requirements
> (outside of security considerations section) about the security
> relationships between CoAP-over-BP requests and responses. Or asked another
> way: must a bundle containing a CoAP response have at least the same
> layer/type/level of security as the request?
>
> Part of the complexity of this question is that there can be security at
> BP layer and at CoAP layer (or both) and that can include (or not include)
> authentication, integrity, and confidentiality aspects.
>
>
>
> The example in [1] is somewhat of a special case because it is designed to
> be sent in plaintext, with security as part of the application layer
> design. For CoAP/BP though, for example, if a request includes BPSec
> confidentiality of the payload I would hope/expect that the response must
> also include confidentiality.
>
>
>
> *From:* Carles Gomez Montenegro <[e-mail]>
> *Sent:* Tuesday, March 19, 2024 3:50 PM
> *To:* Sipos, Brian J. <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Anna Calveras Auge <
> [e-mail]>
> *Subject:* Re: [EXT] [dtn] Fwd: New Version Notification for
> draft-gomez-core-coap-bp-00.txt
>
>
>
> *APL external email warning: *Verify sender [e-mail] before
> clicking links or attachments
>
>
>
> Hi Brian,
>
>
>
> First of all, apologies for the delay in this response.
>
>
>
> Many thanks for your encouraging, detailed and helpful feedback!
>
>
>
> Please find below our inline comments/responses:
>
>
>
> On Fri, 1 Mar 2024 at 16:42, Sipos, Brian J. <[e-mail]>
> wrote:
>
> Authors,
>
> This looks like a good starting point for this kind of layering and
> leveraging of existing application-side tools over a new transport.
>
> I have a few feedback comments about clarifying behavior:
>
>    1. It is important for applications to define appropriate Bundle
>    Lifetime durations for each ADU being sent. This allows the network to
>    delete bundles when appropriate (and also avoid deleting when
>    inappropriate) and avoids application-level retries acting in conflict with
>    BP-level retention logic. The bundle Lifetimes could be set to correspond
>    with the EXCHANGE_LIFETIME to make that explicit and controlled, with
>    response messages’ Lifetimes adjusted appropriately.
>
>
>
> Agreed!
>
>
>
> We plan to address your comment in the next draft update. One detail is
> that we probably need to set the bundle lifetime to EXCHANGE_LIFETIME for
> bundles carrying CoAP CON messages, and NON_LIFETIME for bundles carrying
> CoAP NON messages.
>
>
>
>
>    1.
>    2. The document doesn’t have any explicit logic about response data
>    and bundle source/dest EIDs. BP itself doesn’t have any intrinsic logic of
>    what a “response” means, so it’s up to an application to define the Source
>    EID and Destination EID of a response relative to the
>    bundle-being-responded-to (see [1] for an example). This doesn’t need to be
>    complex logic, but does need to be defined by the BP application.
>
>
>
> Thanks a lot. The example is indeed very helpful! Again, to be addressed
> in the next draft update.
>
>
>
>
>    1.
>    2. Related to your aside at the end of Section 4.1 about the use of BP
>    Status reports to elide application acknowledgement: this assumption is
>    probably incorrect, as status reporting contains lots of other information
>    not pertinent to the CoAP ACK logic. Also, because there is currently not a
>    well-defined scope for BPA—application interfaces a BPA receiving a status
>    report does not necessarily give any visibility to the BP application.
>    Current BPA implementations tend to treat status reports as accounting
>    events similar to ICMP messages, where the application is not involved or
>    informed.
>
>
>
> Admittedly, this "optimization attempt" aimed to (according to some
> numbers we have) save a few (although not many) bytes to be transmitted,
> hoping that it would compensate the additional complexity of this special
> handling. I am wondering if future implementations might offer a BPA -
> application interface, but if this proposal is not really worth it, even if
> it is offered as a "MAY", we can of course abandon it.
>
>
>
>
>    1.
>    2. In the URI definition of section 8.1 it is important to indicate
>    that the embedded EID (which itself is a URI) must be percent-encoded when
>    embedding. And the percent-encoded-EID really just conforms to the
>    “reg-name” rule of [2] and doesn’t involve the “port” rule at all.
>
>
>
> Yes, we plan to address your comment it in the next draft revision.
>
>
>
>
>    1.
>
>
>
> Looking forward to seeing experiments with this layering!
>
>
>
> Great, thanks!
>
>
>
> Such experiments are indeed in our roadmap (in the mid-long term), and we
> are of course also interested in similar initiatives from other
> participants.
>
>
>
> Cheers,
>
>
>
> Carles (on behalf of the authors)
>
>
>
> Brian S.
>
>
>
> [1]
> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-12.html#section-3.4
>
> [2] https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2
>
>
>
> *From:* dtn <[e-mail]> *On Behalf Of *Carles Gomez Montenegro
> *Sent:* Friday, March 1, 2024 4:52 AM
> *To:* [e-mail]; [e-mail]
> *Cc:* Anna Calveras Auge <[e-mail]>
> *Subject:* [EXT] [dtn] Fwd: New Version Notification for
> draft-gomez-core-coap-bp-00.txt
>
>
>
> *APL external email warning: *Verify sender [e-mail]
> before clicking links or attachments
>
>
>
> Dear CoRE and DTN WGs,
>
>
>
> Please find below the main pointers to the initial version of a draft that
> aims to specify how CoAP can be carried over BP.
>
>
>
> We look forward to receiving your feedback!
>
>
>
> Best regards,
>
>
>
> Carles and Anna
>
>
>
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Fri, 1 Mar 2024 at 10:39
> Subject: New Version Notification for draft-gomez-core-coap-bp-00.txt
> To: Anna Calveras <[e-mail]>, Carles Gomez <
> [e-mail]>
>
>
>
> A new version of Internet-Draft draft-gomez-core-coap-bp-00.txt has been
> successfully submitted by Carles Gomez and posted to the
> IETF repository.
>
> Name:     draft-gomez-core-coap-bp
> Revision: 00
> Title:    Constrained Application Protocol (CoAP) over Bundle Protocol (BP)
> Date:     2024-03-01
> Group:    Individual Submission
> Pages:    19
> URL:      https://www.ietf.org/archive/id/draft-gomez-core-coap-bp-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-gomez-core-coap-bp/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-gomez-core-coap-bp
>
>
> Abstract:
>
>    The Bundle Protocol (BP) was designed to enable end-to-end
>    communication in challenged networks.  The Constrained Application
>    Protocol (CoAP), which was designed for constrained-node networks,
>    may be a suitable application-layer protocol for the scenarios where
>    BP is used.  This document specifies how CoAP is carried over BP.
>
>
>
> The IETF Secretariat
>
>
>
> [image: Image removed by sender.]
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
> Libre de virus.www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
>
>
>