Re: [dtn] BPv7 compliance and handling of unknown EID schemes

[Erik Kline <[e-mail]>]

There are a couple of crypto RFCs that are mostly (entirely?) test
vectors.  This obviously makes sense for that specific context, but an
"implementation guidance" doc for BPv7 with test vectors accompanying
advice would seem like a Good Thing (tm) imho.

On Tue, Mar 5, 2024 at 2:04 PM Sipos, Brian J. <[e-mail]> wrote:
>
> All,
>
> There is something that I’ve seen a few times in different contexts related to EID handling that has the potential to lead to highly “ossified” state for BPv7 and cause lack of interoperability or lack of future compatibility (as spelled out in great detail in RFC 9170 [3]).
>
>
>
> BPv7 requires EIDs in a few different places; beyond the three uses in the primary block there are also the Previous Hop block, Security Source within security blocks, and within Status Report records. The BPv7 spec has a well-defined notion of what a valid EID structure is from Section 4.2.5.1 [1] and this structure is codified in Appendix B as the simple CDDL expression:
>
>                eid-structure = [uri-code: uint, SSP: any]
>
>
>
> In some cases a BPA implementation might choose to consider invalid any EID with an unknown scheme `uri-code` value. The problem is that this BPA will now fail in situations that it should not:
>
> It might not be able to forward a bundle having an unknown EID scheme in its Destination, even if the BPA has a kind of “default route” forwarding policy that would otherwise handle the situation properly.
> It might no longer be able to properly status bundles that use an unknown EID scheme in the bundle Source, even if the Report-To EID scheme is known and routable and the bundle is otherwise fully valid.
> It might not properly treat the primary block as immutable if the Report-To EID uses an unknown scheme and the primary block is re-encoded.
> It might consider a Previous Hop block to fail processing, triggering Step 4 of Section 5.6 “Bundle Reception” (and possibly deleting the bundle with reason “Block unsupported”), even though the block data is well-formed and valid according to [1].
> It might treat a security block as invalid if it contains a Security Source EID having an unknown scheme even though the block data is perfectly well-formed and valid according to [1]. Just because the EID will not match any security policy on the BPA does not mean that the block is invalid.
>
>
>
> This is a different situation than, for example, the CRC Type field which has a fixed set of valid code points [2] and any others represent invalid content. Any EID which matches the `eid-structure` schema should be treated as valid by a BPA and handled appropriately. This means the EID `SSP` is kept in its original form without any further processing so that, e.g., a bundle Source or Report-To EID is not modified by a BPA during reception or forwarding.
>
>
>
> The examples above could even be turned into test vectors to check the proper behavior of a BPA with unknown EID scheme code points. I suspect that current BPA implementations might not handle these cases well.
>
>
>
> Others’ thoughts on this topic are appreciated. My goal here is not to nitpick or finger-point, but to ensure that BP and BPAs do not fall into the same traps that others have landed in (see examples in Appendix A of [3]) while development is fresh and there is still time to correct things.
>
> Brian S.
>
>
>
> [1] https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.5.1
>
> [2] https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.1
>
> [3] https://www.rfc-editor.org/rfc/rfc9170.html
>
>
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn