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/ .
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
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.
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)
3.2.1. Allocator Identifier Ranges
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.
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?
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).
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)?
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.
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.
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.
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?
Thanks in advance for your reply.
Best regards,
JMC.