[Int-dir] Re: Intdir telechat review of draft-ietf-dtn-ipn-update-11

[Rick Taylor <[e-mail]>]

Hi Jean-Michel,

Thanks for the review, comments inline...

Cheers,
Rick

On Tue, 18 Jun 2024 at 16:34, Jean-Michel Combes via Datatracker <
[e-mail]> wrote:

> Reviewer: Jean-Michel Combes
> Review result: On the Right Track
>
> Hi,
>
> I am an assigned INT directorate reviewer for
> draft-ietf-dtn-ipn-update-11.txt.
> These comments were written primarily for the benefit of the Internet Area
> Directors. Document editors and shepherd(s) should treat these comments
> just
> like they would treat comments from any other IETF contributors and resolve
> them along with any other Last Call comments that have been received. For
> more
> details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> <https://datatracker.ietf.org/group/intdir/about/>.
>
> Based on my review, if I was on the IESG I would ballot this document as NO
> OBJECTION.
>
> The following are other issues I found with this document that SHOULD be
> corrected/clarified before publication:
>
> 3.2.  Allocator Identifiers
>
> <snip>
>
>    If a system does not require interoperable deployment of ipn scheme
>    URIs, then the Private Use Node Number range, reserved by the Default
>    Allocator (Section 3.2.2) for this purpose SHOULD be used.
>
> <JMC>
> IMHO, it should be clearer (1) to have a reference to Section 3.4.3
> instead to
> Section 3.2.2 and (2) to add the following information in text: - Allocator
> Identifier SHOULD be set to zero (0) - Node Number SHOULD be in the
> “Private
> Use” range (cf. Section 9.2) </JMC>
>
> <snip>
>

You make a valid point, but we have decided to replace the "SHOULD be used"
with "are to be used" (not canonical).  I'm not keen to start talking about
Id 0 at this point, as we have yet to introduce numeric values
(representation detail) and are just talking about generalities, but I have
added a cross reference to 3.4.3


>
> 3.2.1.  Allocator Identifier Ranges
>
> <snip>
>
> With these assignments, any Allocator Identifier whose most-
>    significant 25 bits match 0xEE000 belong to organization A.
>    Similarly, any Allocator Identifier whose most-significant 28 bits
>    match 0xEE080 belong to organization B, and any Allocator Identifier
>    whose most-significant 31 bits are 0xEE090 belong to organization C.
>    Organisation D has a single Allocator Identifier, and hence a range
>    of bit-length 0.
>
> <JMC>
> Sorry, but I don’t understand how you get 25 bits for organization A, 28
> bits
> for organization B and 31 bits for organization B. Is it possible to
> provide a
> formula, please? By the way, are you assuming that Allocator Identifier is
> based on 32 bits? </JMC>
>
> <snip>
>

We were really hoping that this read as 'subnet masking' written in
longhand.  And yes, Allocator Ids are all 32-bit unsigned ints. But having
re-read, we don't specify that by this point, will update.


>
> 3.4.  Special Node Numbers
>
>    Some special-case Node Numbers are defined by the Default Allocator,
>    see 'ipn' Scheme URI Default Allocator Node Numbers registry
>    (Section 9.2).
>
> <JMC>
> It seems that you assume that there will no need of special-case node
> numbers,
> except for the Default Allocator, in the future: is it correct? If so, is
> it
> not dangerous (i.e., complexity to come back from such a decision)? </JMC>
>
> <snip>
>
> 5.5.  Private Use ipn EIDs
>
>    Bundles destined for EIDs that use an ipn URI with a Fully-qualified
>    Node Number (Section 3.3.1) that is within the "Private Use" range of
>    the Default Allocator (Section 3.2.2) are not universally unique, and
>    therefore are only valid within the scope of the current
>    administrative domain.  This means that any bundle using a Private
>    Use ipn EID as a bundle source or bundle destination MUST NOT be
>    allowed to cross administrative domains.  All implementations that
>    could be deployed as a gateway between administrative domains MUST be
>    sufficiently configurable to ensure that this is enforced, and
>    operators MUST ensure correct configuration.
>
> <JMC>
> IMHO, “MUST” use may be too strong: it is possible that 2 administrative
> domains (e.g., two affiliates in a same company) agree to use ipn URI in
> the
> “Private Use” range and to choose different subsets of this last one to
> ensure
> uniqueness. </JMC>
>
> <snip>
>

We went back and forth on this, but for the purposes of this text, we
define "administrative domain" to include "two cooperating admin domains
with an out-of-band mechanism to sub-allocate the private use range to
avoid clashes", so I think we have your point covered without explicitly
describing it.


>
> 8.2.  Malicious construction
>
>    Malicious construction of a conformant ipn URI is limited to the
>    malicious selection of Allocator Identifiers, Node Numbers, and
>    Service Numbers.  That is, a maliciously constructed ipn EID could be
>    used to direct a bundle to an endpoint that might be damaged by the
>    arrival of that bundle or, alternatively, to declare a false source
>    for a bundle and thereby cause incorrect processing at a node that
>    receives the bundle.  In both cases (and indeed in all bundle
>    processing), the node that receives a bundle should verify its
>    authenticity and validity before operating on it in any way.
>
> <JMC>
> There is no reference to any security mechanism to prevent such a threat:
> no
> security mechanism – equivalent to IP anti-spoofing, exists regarding this
> threat? </JMC>
>

Yes there is: RFC9172 (BPSec) describes an
integrity/confidentiality mechanism which can enforce identity at the
bundle layer, and RFC9174 defines a convergence (link) layer protocol that
includes TLS with support for Node IDs as part of peer certificate
exchange.  I'll add a reference.

>
> Thanks in advance for your reply.
>
> Best regards,
>
> JMC.
>
>
>
>