Hi Jean-Michel,
Thanks for the review, comments inline...
Cheers,
Rick
On Tue, 18 Jun 2024 at 16:34, Jean-Michel Combes via Datatracker <noreply@xxxxxxxx> 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.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
