[dtn] BPv7 compliance and handling of unknown EID schemes

["Sipos, Brian J." <[e-mail]>]

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:

1.	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.
2.	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.
3.	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.
4.	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].
5.	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